Perimeter
10/8/2012
05:21 AM
Wendy Nather
Wendy Nather
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

When Monitoring Becomes A Liability

The combination of 'bigger data' and 'more intelligence' could lead down a path that creates problems for the enterprise

Organizations generally want to keep breaches under wraps, or at the very least to control the release of any news about them. When you have mandatory reporting laws in place, it can simply motivate you either to monitor less -- what you don’t know, you can’t report -- or to take longer to decide that it’s really a compromise that needs to be reported.

Here’s an example: If you discover that some Social Security numbers were theoretically accessible on an Internet-facing Web server, but you have no logs to figure out whether they were ever accessed, then what do you do? Is it a breach, or isn’t it? Does it matter whether they were there for an hour, or a day, or a month? If something confidential is accidentally published and the mistake is caught right away, then most organizations are simply going to go, "Oops," take it down, and say no more about it. (If you think this is shocking and scandalous, you don’t understand your business.)

But there’s a growing problem: Not all the indications of a security issue are under the control of the enterprise itself, and not all of them are subject to interpretation. One practice that is very common is the externally mandated audit or vulnerability assessment: where an external authority is empowered to examine and report on your security controls, or even pen test you, and publish some form of report. While you may argue that allowing SSL 1.0 doesn’t represent any kind of significant security risk, it’s not going to convince the auditor to drop it from the checklist. And in publicly available audit reports (such as the ones in the public sector), descriptions of findings are kept intentionally vague so as not to give clues to would-be attackers.

But this can also mean that "there is a weakness in transaction security" actually translates to "still allows a few remaining ancient browsers to use SSL 1.0." And the organization in question probably won’t be able to explain the real story.

Debating the seriousness of a given vulnerability is one thing; after all, having that vulnerability doesn’t necessarily mean it’s being exploited. But more unambiguous indicators are out there for anyone to find, such as membership in a botnet. If something in your IP address range is talking to a known command-and-control center, then at least at one level you’ve been 0wn3d, and you can’t explain it away with a +5 Wand of Pragmatism.

Not only is botnet membership publicly available for anyone who cares to look -- a lot more are caring to look now. Threat intelligence is growing at a steady pace, and the data is coming not just from a vendor’s product logs, but from honeypots and sensors deployed across the Internet. Several companies will now offer to tell you if you’ve been compromised by searching through their very large stores of data for your IP addresses; others can also monitor Pastebin, IRC, and other areas for any data related to your company.

For right now, at least, this sort of threat intelligence is governed by a gentlemen’s agreement that any indications of a breach will be supplied to only the affected party. But how long will it stay that way? We already have regulating authorities that would probably be very interested in knowing whether a financial institution, government agency, or healthcare provider actually has compromised machines -- and they might have the legal right to know. There is nothing to stop an unaffiliated party from gathering its own botnet membership information and publishing it (except, perhaps, the threat of lawsuits). Is the release of publicly available information illegal?

We’re not there yet, but the Wikileaks-style data exposure trend may well extend to general breach disclosure that organizations will have no way to stop. Naming and shaming could become a lot more widespread: "The National Bank of Freedonia has had at least four systems in a botnet every day for the past six months." And it could become shorthand for indicating how secure an enterprise is -- a breach index, if you will.

The more security intelligence data grows, and the more we can do with it, the greater the chances become that it could be a double-edged sword. Sometimes it’s possible to know too much.

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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web