Analytics // Security Monitoring
7/13/2012
05:13 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Black Hat Researcher: Rethink And Refine Your IDS

Attackers routinely go unnoticed, both because intrusion detection systems are failing to do their jobs and because security teams need to rethink how they use them

When a company finds out that an attacker has been in its network and stealing data, it's rare that its intrusion detection system (IDS) is the key to the discovery. More often, as shown by the 2012 Verizon Data Breach Investigations Report, data is stolen within hours, but the breach is found weeks or months later when the attackers use the data.

   
Click here for more of Dark Reading's Black Hat articles.

A large part of the problem is that IDSes have not kept up with attackers. But another part of the problem is companies are not properly managing the systems, according to John "Four" Flynn, a security engineer with Facebook, who plans to argue in a presentation on their failures at Black Hat USA later this month. For example, breached companies were more likely to find intruders through manual log analysis than by alerts generated by their IDSes, according to the Verizon report.

"When you actually dive into the details of how these systems are working against the modern, targeted attack that a lot of the enterprises are dealing with today, you find that the efficacy of these systems leaves a lot wanting," Flynn says. "It is pretty appalling. We need kind of a reset here."

He's not alone in criticizing IDSes and how they are being used by companies. The systems inundate security teams with data, need constant tuning, and have not kept up with attacks, says Bryan Sartin, director of intelligence for Verizon's RISK group.

"People are attacking modern electronic crimes with tools and method out of the mid-'90s," Sartin says.

While Facebook's Flynn plans to criticize IDSes, the bulk of his presentation will be on how companies can improve the performance of the systems.

[ U.S. critical infrastructure companies saw a dramatic increase in the number of reported cyber-security incidents between 2009 and 2011. See U.S. Critical Infrastructure Cyberattack Reports Jump Dramatically. ]

Businesses need to think about the event pipeline that leads to the identification of potential anomalies that could indicate a security problem, he says. Most companies attempt to collect as much data as can be automatically processed and then generate the most reliable, actionable alert.

"They take a Snort sensor and turn off everything that makes too much noise, and then the rest of it, presumably, will let them know in the middle of the night that there is an attacker there," he says. "It's completely the wrong approach."

Instead, companies should collect metrics that may be able to identify suspicious activity. Flynn created a taxonomy, rating such data from a level 10, meaning data from which no action can be taken, to level 1, which is an all-hands alert. Most companies have volumes of level-10 data -- such as log data -- and want level-1 alerts, but should be paying attention to all the levels in between, he says.

"This is a tremendous amount of data that you can instrument in your environment that can be useful for the intrusion detection problem," Flynn says. "They are largely ignored because they are not actionable enough in and of themselves."

For example, a company could track interesting registry modifications on the company's systems -- level-5 information. By bringing that into the pipeline of data and events that are tracked, companies are better prepared to discover abnormal behavior, he says.

In addition, by adding the military concept of a "kill chain" -- the steps necessary for an attacker to accomplish their mission -- companies can have a framework for analyzing potential events and identifying them as part of an attack. Typically, the military strives to shorten the kill chain when on the offense and attempts to lengthen the kill chain on the defense.

By looking at attacks in the context of the kill chain, defenders can ignore specific techniques and look for the steps necessary to complete a kill chain.

"You can utilize it as a way to do more advanced correlation," Flynn says. "If you can figure out a way to tag each event with the stage they are part of, you can stack the events in a way that lets you analyze them in terms of potentially part of a kill chain."

While Flynn may be overstating the deficiencies of IDSes -- he calls the field "a complete failure" in his online abstract -- the idea of using the kill chain to analyze events can help companies improve their processes, says Mike Lloyd, chief technology officer for RedSeal Networks.

However, many businesses may find more security dividends by investing in the basics, such as stronger passwords and authentication, better monitoring of network resources, and other simple measures.

"The kill chain analysis is a good second level to think about, but before you start stepping up to the next level of live detection, I think companies need to look at what else we can do that is better," Lloyd says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

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