Analytics // Security Monitoring
4/23/2013
02:23 AM
Wendy Nather
Wendy Nather
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Did The Dog Bark In the Night?

What we still don't know, despite the data

There are many threat and breach reports out there, and many are very good, but I do confess that my favorite after all these years is still the Verizon Business Data Breach Investigations Report. Not only does it have the largest sample size (with 19 partners adding their data this year), but it also has innovative graphics and an open discussion about the limitations of its data. It's hilarious to read. By "hilarious," I don't mean, "Do they realize their fly is open?" hilarious, but the kind of hilarity you get when you buy enough tureen-sized drinks for risk analysis geeks.

When you have bad data, you quickly run out of things to do with it. When you have great data, the more you examine it, the more questions it prompts. Take, for example, the updated statistics on third-party notification -- 52% of breaches at large enterprises and 23% at small enterprises were first noticed by unrelated third parties, and almost all of those were cases of espionage. (This doesn't include breaches that were detected by common point-of-purchase fraud detection, by the way; those are considered to be related parties.)

First of all, you would think that the larger percentage would be at smaller enterprises; aren't they the ones who are less likely to be able to find things themselves? On the other hand, espionage probably targets larger enterprises, so maybe it makes more sense the way it is.

But there's a third thought buried in here: Could it be that more breaches are discovered by unrelated third parties because of the growth of threat intelligence overall? If you put more intelligence in the hands of central traffic nodes such as ISPs, then they're bound to find more in what they're already seeing. And if there are more threat intelligence vendors, then they are more likely to contact enterprises when they see indicators of compromise that they already know from other cases. So this increase might actually be a good sign.

One more heretical thought: The DBIR doesn't contain any information about the failures of organizations to detect their own breaches. Is it that they weren't doing any monitoring? Were they monitoring, but just not doing it very well? Or did they have all the latest and greatest security monitoring tools, but they didn't actually work?

I'm just going to leave that out there for the next round of drinks.

Wendy Nather is Research Director of the Enterprise Security Practice at the independent analyst firm 451 Research. You can find her on Twitter as @451wendy. Wendy Nather is Research Director of the Enterprise Security Practice at independent analyst firm 451 Research. With over 30 years of IT experience, she has worked both in financial services and in the public sector, both in the US and in Europe. Wendy's coverage areas ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.