IDS and IPS
This is the third post in a series that focuses on a view from the trenches. In this post I will examine inline and passive intrusion prevention/detection installations. Although the industry trend is that the automation aspects of inline IPS make it more useful, does that mean that passive intrusion detection as a technology is obsolete? While the benefits of inline IPS are easy to see, I want to point out a few situations where it may still be useful to use passive intrusion detection.
There is a debate today on the value of IDS/IPS and whether IDS has to be inline to be valuable. (See my previous posts for more background on the merits of IPS.) At first, all intrusion detection was passive, looking for attack signatures on the wire. Of course predictively analyzing and detecting all attacks has an inherent conflict: if we can predict it enough to analyze it with a high degree of fidelity, we could just prevent it. This set the stage for an inline preventative IDS (IPS). The intrusion detection market has been progressively moving in this direction. One of the business influences leading to that trend could be described as follows:
A company has a small security team, they purchase and deploy IDS for $1000 and get many alerts; their security posture remains static. The company purchases SIM for $1000 to help manage alerts and their security posture remains static. The company then hires more people to tune, manage, and respond to their IDS deployment and, a year or two down the road and $100,000 later, they start to identify and reduce issues.
In today’s fast-changing world, the return on investment (ROI) is hard to justify and is a long time coming. Switch to IPS and that same small security team buys and deploy something inline for $1000 and their security posture starts to improve immediately. Is IDS dead? Is IPS the only way to go? Read on to find out.
I meet with security teams all over the world and most have some form of intrusion detection deployed. Generally, there are some major, big buckets of intrusion detection deployment/implementation types:
- Type 1: A few sensors are deployed, no one is looking at them or is even sure what networks are covered or not covered.
- Type 2: Intrusion detection is deployed through an outsourced service. There is a good understanding of what is covered and there is a good management of events, but only a few high fidelity signatures are running (or are viewed). This type of implementation is typically static and can be considered a sort of network anti-virus service.
- Type 3: Intrusion detection is deployed over all applicable choke-points, managed, and tuned with the security team using multiple signatures — many signatures that are custom-developed to solve ongoing security issues at the site.
I wish all teams were closer to Type 3, but I often find that they are closer to Type 1. Many teams deploy intrusion detection as a checkbox for compliance rather than deploying it with a real interest in using on-the-wire detection to protect the network. This can be related to ROI issues and the setup time mentioned earlier in this post. IPS is often considered the quick fix, but what are you missing if you go that route? Why doesn’t everyone go inline and leave their old passive IDS forever? Here are a few reasons that could make the difference:
- Flexibility: With passive intrusion detection, we can institute new signatures at will. Cisco regularly releases new signatures, but we can also install experimental, custom signatures because passive detection gives us the flexibility to deploy highly specific detection around critical or unique areas and threats. We deploy signatures for hot threats that may only be relevant for a week or two. Testing for operational impact, success of signature fidelity, and deployment within this environment may exceed the life cycle of the hot threat. If we are 100% inline, we lose much of that flexibility and all of the corresponding intelligence. Inline is in critical path. With passive intrusion detection we can institute new signatures without impacting data streams. With IPS, we run some risk of interrupting traffic for each signature. We have to do testing before deployment to ensure we don’t knock anything over. Inline, we are also not at liberty to update at will and must fit in with change management and data center freeze schedules.
- Bandwidth: We have some data centers with pretty big pipes. If we are passive and we exceed capacity, we lose some of the packets for monitoring purposes. If we are inline, we could drop packets. So we go from loss of monitoring to a loss of service.
- Need: Given the need for high-fidelity signatures that block when they fire, we are limited to acting on issues that can be determined at light speed (such as signatures that require little or no secondary validation). That in practice means blocking well-known malware. A company may not need to auto-mitigate viruses through hardware blocking at gateways. IPS can block clearly defined, well-known bounded attack types.
- Roles and Responsibilities: At Cisco, our team is not part of IT. We have the autonomy to find issues anywhere. As soon as we are part of delivering that network, we lose some of that objectivity. IPS needs to be a partnership where IT runs/maintains the gear and the security team helps with the policies.
- Effort: Many networks have grown to be very fault-tolerant and redundant and may not have the choke points to make auto-mitigation effective. This scenario could force some form of network re-architecture in order to make IPS useful.
So does this mean IPS is useless? No, not at all. There are some very good deployment scenarios. For example, IPS can be very effective if you are joining two areas with very different security postures, especially if one area has problems with malware that you may not be able to completely fix, possibly from a lab to a production network. For example, at Cisco we are trying IPS between our remote access network and our internal network. The below is a network diagram on a functional setup for IPS.
This allows remote users to have more freedom while not hurting our corporate network. The details in this post highlight the argument that IPS/IDS doesn’t have to be mutually exclusive. It really is what solution fixes your security problems and the answer could be both. At Cisco, we will continue to have a huge investment in passive IDS for network intelligence gathering, while using IPS to block some very unequal security posture junctions. Using IDS, we have enabled the business to move quickly into new opportunities with the ability to tell if things get out of hand. The main decision-making factor with IDS/IPS should be choosing the direction that solves the types of security problems that are facing the network.