About INetU

IPS vs. IDS, How Do They Affect Your Network Security?

Posted: 01/22/2013

Intrusion Protection System and Intrustion Detection System (IPS/IDS) devices are an important layer in the overall network security profile of any business. They provide a basic sanity check on traffic to and from your network that your firewall has deemed acceptable to pass. It’s part of the defense in depth initiative that any security conscious company should employ. Each layer is responsible for a particular security check. IPS/IDS units check traffic that has passed the basic access control list on the firewall for any potentially known bad payload.

How they do this? Well, here is a basic understanding of IPS/IDS.

Traffic Control

First, we will start with getting traffic to the device. In most cases, you can put the sensor inline (IPS mode), or out of line (IDS). In IPS mode, you are performing inspections and pattern matching as the live traffic passes through the sensor. In IDS mode, you are performing those security inspections and pattern matching on copied traffic, so it does not affect the flow of live traffic. Typically, the implementation style is a business decision that differs between companies and depends on a device manufacturer being implemented.

Once you have the topology decided upon, you can then determine which traffic gets inspected. Typically, you would want all server traffic to be checked against the signature database. But, there may be exceptions to this, so this would need to be determined based on your business drivers. Once this is all set, the traffic you want to check will start flowing through the sensor.

The signature database is the crux of the IPS/IDS unit. The effectiveness of the device is only as good as the signatures you are checking the traffic against. You want to make sure your device is getting the latest signatures for the most effective use. Most of the larger vendors maintain a very tight and up to date signature line which is pushed to their sensors on a frequent basis.

As traffic passes through the device, it is compared against various signatures within a device. Signatures are grouped into engines based on their function. Signature engines are very powerful, and we could write a blog article just on them, but for this article, I will just glance over the main ideas. These signatures engines can be of different types. For example, they may look for a particular string within the payload, which is also known as a string signature. They may also look for a particular action on a specific port. These are known as atomic or service types of signatures. Next, there are those that can look for large amounts of requests by that same person over a particular time period, which are known as the flood type. Meta type signatures can watch for a known bad pattern over a sliding window of time. For example, someone telnets to port 25 with a given string, and then within 1 minute, sends a particular ICMP type.

Network Risk Rating

When server traffic matches any of the signatures, the sensor determines how much of a security risk this match is before it categorizes the attack into a Risk level. With Cisco, the Risk Rating (RR) formula determines this. The RR is a number from 0 to 100 that determines the risk of this attack on your network. The RR is determined based on the following:

  • Signature fidelity rating – basically the confidence level/accuracy of this signature hit. Does this signature hit typically result in attacks, is it typically benign, or somewhere in between?
  • Attack Severity rating – a weight assigned to the signature based on the success rate of the vulnerability
  • Target value rating – a weight assigned to the target; You can give different devices in your network different weights based on how important they are
  • Attack relevance rating – a weight assigned to how relevant the attack is on that target; For example, if the target is a Linux box, and someone is attacking with a Windows exploit, the attack is not as relevant as a Linux exploit would be
  • Promiscuous Delta – takes into consideration how the sensor is configured
  • Watch List rating – checks to see if the attacker is a known attacker based on CSA watch lists

Those values are then put through a formula, and the attack is assigned a risk level of low, medium, or high (custom risk levels can also be created). Based on the actions set for each risk level, that action will be performed. Actions could be: drop that packet, block that attacker, shun, just log, etc. There are lots of actions to perform based on your business drivers and overall security policy.

IPS vs IDS, How To Make The Right Decision Based on Business Requirements?

The next decision is whether to operate in IPS or IDS mode. Each has their own respective Pros and Cons, and implementation will depend on a couple different business decisions and requirements. In the following paragraphs, I will explain the options available to you.

I have a lot of people come up to me and ask me whether they should implement their Intrusion Detection System in IDS or IPS mode within their environment. The answer really depends on your risk acceptance, business requirements and the hardware you have. The terms typically refer to position in the network and how they interact with the traffic rather than physical device, as most IPS sensors today can work in both inline or in promiscuous mode. Let’s dive a little deeper to hopefully help you answer the question.

First, let’s talk about your business requirements. What are your requirements for implementing this technology? Obviously, it is to add better protection in your network. The main difference between these 2 types of technology is one is watching/acting upon a copy of the traffic (IDS) and the other one is watching/acting upon real traffic (IPS). IPS sensors are inline, so traffic is forced to pass through them in your environment. For IDS sensors, they are typically deployed were a copy of traffic off a span port is sent to them for inspection. So, I you want to be alerted of situations, and not affect real traffic, or maybe not need to act upon an initial threat, or even a zero day offense, IDS may be for you. Problem here is that since it is only watching/alerting copied traffic, the real offending packet(s) have already passed to their intended target. Even if you have your IDS setup to update your firewall with blocking rules, the initial attack packet has already gone through. If you want to block an atomic attack ( single packet attacked ) that will get though the IDS, then maybe you should consider the IPS implementation. The IPS implementation can act upon the traffic as it sees it, so it can block that first initial packet that may be a start of an attack, or even a recon of some sort. Based on this, you may have a clear idea of what you want now, but you need to consider the risk levels between the two implementations.

Business and Security Risks of IDS vs IPS

Now, let’s talk about risk. The IPS technology tends to bring more risk to the table then the device in IDS does. The reasoning for this is that the IPS has live traffic passing through it since it’s inline. So if it fails, or becomes overwhelmed, it will affect your live traffic. This can cause availability issues if not planned out correctly. Now some IPS devices have failure technologies built-in to either fail-open or fail-closed in the case of a device failing. Fail-open means that if the IPS device fails, it will continue to pass traffic, and will just not inspect it. Fail-closed means that if the IPS is not able to inspect traffic, no traffic will pass. This decision will need to be made based on your security policy. But remember, this feature tends to only happen if there is a true hardware failure. Sometimes the application can fail, and that can cause an outage, as the box technically isn’t failed in its mind. One example may be, if availability is more important to you than security, then IDS may be the better option, or IPS in fail-open mode. But, if top security is your ultimate goal, than the IPS may be a better option in fail-closed mode. There are some slight risks with IDS though, in my opinion. They are less severe in terms of the SLA issue above, but can be just as bad in the long run. If you are running in IDS mode, you are most likely just getting alerted of potential issues. But what is happening with these alerts? You need to make sure you have good SOP’s (Standard Operating Procedures) in place. The last thing you want to do is implement this system, it alert, but no one pays attention to it. When an IPS is implemented, it is actively protecting your traffic whether you are watching or not. So, proper configuration and monitoring is essential.

Hardware Check for IPS/IDS

Lastly, the type of hardware can make the decision on what you are implementing. Some hardware only works as IDS. Some vendors stick with IDS technologies rather than both IPS/IDS. So you need to check with your vendor on what options are available for you to use. Either way, make sure your hardware is able to keep up with your traffic load. As mentioned before, not having enough hardware can potentially cause network issues with an IPS (especially with fail-closed enabled ), and bad traffic to pass unchecked ( in IDS and IPS with fail-open enabled ) due to the device not being able to handle the traffic load or type of traffic.

Hopefully this article will shed some light on not only how IPS/IDS units work, but also the best way for your company to implement them. The goal here is to implement these technologies smartly, as a poor implementation can sometimes be as bad as no implementation at all. Remember, Defense in depth is essential is today’s world. The more layers of network protection you have, the better you are in the long run.

Click here to read more about IDS/IPS and here to learn more about deciding which one to use. Stay tuned for more articles in this security series.

Find out more about INetU Data Security and how we can help your business.


comments powered by Disqus

Subscribe To Our Blog

Search Our Blog

Featured Authors

Andrew Hodes
Chief Technology Officer
Read Bio
David Fowler
Vice President of Marketing

Read Bio
Dev Chanchani
CEO and Founder

Read Bio
Eric Naiburg
Director of Product Management

Read Bio
Jeanine Sicinski
Partner Program Manager

Read Bio
Lindsay Glen
Marketing Communications Specialist

Read Bio
Rich Hand
Technical Solution Engineer

Read Bio
Scott Walters
Director of Security
Read Bio
More Archived Blog Posts...