Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/30/2007
07:55 AM
50%
50%

Outer Limits of IPS

Anomaly- and rules-based protections are nice, but they have their limitations

5:55 PM -- When traffic spikes, are you actually under attack? Will deployed intrusion prevention hardware start blocking traffic to your site? Is it safe to block that traffic -- especially automatically?

These are the questions you should be asking yourself if you are going to deploy an intrusion prevention system (IPS).

Several years ago Richard Stiennon -- then still with Gartner -- told the world that the intrusion detection system (IDS) was dead. He was talking about the fact that companies don't recoup their costs by deploying something that simply monitors that they are under attack. Rather, he argued, they should instead invest in a smarter solution that actually does something to prevent the attack, like -- an intrusion prevention system (IPS) or hardware to combat distributed denial-of-service (DDOS) attacks.

IPSes are typically no more than glorified rules engines tied in with a firewall. There are different versions; some that send packets to kill the connection (like the great firewall of China that protects the entire country from bad words, like the phrase that's a form of Tai Chi with religious implications). Others simply drop the packets. In the end, the intended effect is the same: The connection with the malicious traffic is disrupted. But is that what you really want? What is triggering these rules?

There are two types of detection, anomaly- and rules-based. Rules-based says that the malicious traffic must perform a particular function that matches what's on the rules engine in order to be blocked. Anomaly is based on the premise that traffic patterns tend to follow a particular pattern. If traffic ever spikes above normal it's an anomaly and it should be stopped.

But here's how each type of detection can easily fail. In the case of the great firewall of China, they send packets in each direction to shut down the connection if they find a bad word. But if someone were to try and encode even vaguely the bad word by reversing the text, using pig latin, or any of a thousand other techniques, then the rules engine would not fire. There are other problems with China's method, in that if you simply ignore the packets they send to shut down the connection, you can continue to route packets. A flawed solution, indeed.

Anomaly detections only detect when an action is performed that should not happen. In the case of a cross-site request forgery, it is trivial to get a valid user to perform an action which then shuts down that connection for that user (not the attacker). If the attacker can get a search engine to follow a link to a function that it should not attempt to go to, your IPS could actually end up blocking the search engines from spidering your site, which hurts your ability to get traffic to your company. This same problem exists for rules engines as well.

However, there is another issue with anomaly detection. Let's pretend you are Victoria's Secret. All year long your traffic is a low rumble. But once a year your traffic spikes so high that any anti-DDOS engine could not ignore it. Do you really want to prevent millions of viewers from watching your online fashion show?

It looks and smells like a denial-of-service attack, but yet it is one of the critical parts of doing business. Granted DDOS and IPSes are trying to solve two different issues, but this is a good explanation of how anomaly detection can create huge false positives.

While both anomaly detection and rules engines have their own unique issues, both have their uses. I wouldn't recommend ditching your IPS dreams of a safe future. But don't hold your breath. The technology has a long way to go before it is capable of that subtle balance between security and invasiveness.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Lessons from the NSA: Know Your Assets
Robert Lemos, Contributing Writer,  12/12/2019
4 Tips to Run Fast in the Face of Digital Transformation
Shane Buckley, President & Chief Operating Officer, Gigamon,  12/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19807
PUBLISHED: 2019-12-15
In the Linux kernel before 5.3.11, sound/core/timer.c has a use-after-free caused by erroneous code refactoring, aka CID-e7af6307a8a5. This is related to snd_timer_open and snd_timer_close_locked. The timeri variable was originally intended to be for a newly created timer instance, but was used for ...
CVE-2014-8650
PUBLISHED: 2019-12-15
python-requests-Kerberos through 0.5 does not handle mutual authentication
CVE-2014-3536
PUBLISHED: 2019-12-15
CFME (CloudForms Management Engine) 5: RHN account information is logged to top_output.log during registration
CVE-2014-3643
PUBLISHED: 2019-12-15
jersey: XXE via parameter entities not disabled by the jersey SAX parser
CVE-2014-3652
PUBLISHED: 2019-12-15
JBoss KeyCloak: Open redirect vulnerability via failure to validate the redirect URL.