Perimeter
9/1/2012
10:16 AM
Wendy Nather
Wendy Nather
Commentary
50%
50%

Talking 'Bout My Reputation

When good security monitoring means not believing everything you're told

Imagine it's next year. OK, imagine a few years from now -- probably not as soon as some might hope -- when we all have monitoring systems that can automatically react based on a number of conditions. And let's say that some of these conditions are based on the output of threat intelligence feeds.

Threat intelligence feeds are growing in number almost daily. Nearly every IDS/IPS, anti-malware, and firewall vendor has one: It starts within the company's own research lab, and then the research is productized, first for direct consumption by its own offerings, and then perhaps for integration with other vendors. SIEM and analytics vendors can either consume externally generated threat intelligence data, or put their own together based on whatever data the customer is collecting. And finally, there are dedicated threat intelligence vendors that build extensive sensor and honeypot networks and use their own proprietary analysis to build a feed. Some vendors collect data; One forensics tool I know uses as many as 96 sources of intelligence feeds for its dashboard.

One large component of intelligence feeds is an overall score for any given entity that is tracked, usually an IP address or range. These might be further tagged by geolocation, industry of the registered owner of the range, and so on, but, in general, the fundamental attribute is an IP address. If bad activity is seen to come from a particular address -- for example, being part of a botnet -- the IP is given a "worse" reputation score. And in an ideal world, any prevention system that used this reputation data would be able to react automatically, for example, by blocking access or alerting a human somewhere.

There's just one problem: IP addresses do not directly correspond with the bad actors behind them. I can take my laptop, go to different locations and have different IPs assigned each time. I'm still the same actor, with the same laptop, but I can be coming from a hotspot in Peoria, an office network in San Francisco, my home network, or my brother's house. And each of those points of presence will have amassed a reputational score that has nothing to do with me. However, I can sure leave a trail of destruction behind me if I behave badly enough.

With great reputation ranking comes great responsibility. How quickly can you get off someone's blacklist after you clean up an infection on your network? I have seen organizations unable to send email for hours or days because they couldn't convince an anti-spam vendor quickly enough that there had been a mistake, or that they were really okay now. It's not necessarily a case of false positives; they might OK have been compromised, but that state existed only for a point in time, and the "bad bit" needed to be cleared.

So the more automatically you respond based on a rating score, the more quickly you need to be able to change that response based on new data. Otherwise, I can't think of anything easier than to create a denial of service attack by generating network traffic to damage a reputation. Why DoS someone directly when you can get scores of intelligence feeds to do it for you?

Call it a reflective reputation attack, or blacklisting by proxy. If enough networks start using the combination of intelligence feeds with automated blocking, it might be the next new form of harassment. If you know all of the factors that go into a rating score, can generate activity to manipulate them, and can spoof the target's IP range, you can at least tie your victim up in a form of bureaucracy while it gets its name cleared by each feed vendor in turn.

So the most important thing about this kind of monitoring is still how you identify and deal both with false-positives and temporary-positives. If you're going to rely on external, automated intelligence, then you need to make sure you keep some in-house intelligence available as well. Plan for failure, and plan for change.

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 December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3407
Published: 2014-11-27
The SSL VPN implementation in Cisco Adaptive Security Appliance (ASA) Software 9.3(.2) and earlier does not properly allocate memory blocks during HTTP packet handling, which allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCuq68888.

CVE-2014-4829
Published: 2014-11-27
Cross-site request forgery (CSRF) vulnerability in IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allows remote attackers to hijack the authentication of arbitrary users for requests tha...

CVE-2014-4831
Published: 2014-11-27
IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allow remote attackers to hijack sessions via unspecified vectors.

CVE-2014-4832
Published: 2014-11-27
IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allow remote attackers to obtain sensitive cookie information by sniffing the network during an HTTP session.

CVE-2014-4883
Published: 2014-11-27
resolv.c in the DNS resolver in uIP, and dns.c in the DNS resolver in lwIP 1.4.1 and earlier, does not use random values for ID fields and source ports of DNS query packets, which makes it easier for man-in-the-middle attackers to conduct cache-poisoning attacks via spoofed reply packets.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?