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

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
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-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.