Perimeter
9/1/2012
10:16 AM
Wendy Nather
Wendy Nather
Commentary
Connect Directly
RSS
E-Mail
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0640
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote authenticated users to bypass intended restrictions on resource access via unspecified vectors.

CVE-2014-0641
Published: 2014-08-20
Cross-site request forgery (CSRF) vulnerability in EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to hijack the authentication of arbitrary users.

CVE-2014-2505
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to trigger the download of arbitrary code, and consequently change the product's functionality, via unspecified vectors.

CVE-2014-2511
Published: 2014-08-20
Multiple cross-site scripting (XSS) vulnerabilities in EMC Documentum WebTop before 6.7 SP1 P28 and 6.7 SP2 before P14 allow remote attackers to inject arbitrary web script or HTML via the (1) startat or (2) entryId parameter.

CVE-2014-2515
Published: 2014-08-20
EMC Documentum D2 3.1 before P24, 3.1SP1 before P02, 4.0 before P11, 4.1 before P16, and 4.2 before P05 does not properly restrict tickets provided by D2GetAdminTicketMethod and D2RefreshCacheMethod, which allows remote authenticated users to gain privileges via a request for a superuser ticket.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Dark Reading continuing coverage of the Black Hat 2014 conference brings interviews and commentary to Dark Reading listeners.