Why Prevention Can Never Completely Replace Detection
So-called intrusion prevention systems (IPS) are all the rage. Since the 2003 Gartner report declaring intrusion detection systems (IDS) dead, the IPS has been seen as the "natural evolution" of IDS technology. If you can detect an attack, goes a popular line of reasoning, why can't (or shouldn't) you stop it? Here are a few thoughts on this issue.
People who make this argument assume that prevention is an activity with zero cost or down side. The reality is that the prevention action might just as easily stop legitimate traffic. Someone has to decide what level of interruption is acceptible. For many enterprises -- especially those where interruption equals lost revenue -- IPS is a non-starter. (Shoot, I've dealt with companies that tolerated known intrusions for years because they didn't want to "impact" the network!)
If you're not allowed to interrupt traffic, what is the remaining course of action? The answer is inspection, followed by manual analysis and response. If a human decides the problem is severe enough to warrant interruption, then a preventative measure is deployed.
In some places, prevention is too difficult or costly. I would like to know how one could use a network-based control mechanism to stop a host A on switch X from exploiting host B on switch X. Unless the switch itself enforces security controls, there is no way to prevent this activity. However, a sensor on switch X's SPAN port could detect and report this malicious activity.
Note that I think we will see this sort of access control move into switches. It's another question whether anyone will activate these features.
I think traffic inspection is best used at boundaries between trusted systems. Enforcement systems make sense at boundaries between trusted and untrusted systems. Note that if you don't trust individual hosts inside your organization (for whatever reason), you should enforce control on a per-host basis within the access switch.
People who make this argument assume that prevention is an activity with zero cost or down side. The reality is that the prevention action might just as easily stop legitimate traffic. Someone has to decide what level of interruption is acceptible. For many enterprises -- especially those where interruption equals lost revenue -- IPS is a non-starter. (Shoot, I've dealt with companies that tolerated known intrusions for years because they didn't want to "impact" the network!)
If you're not allowed to interrupt traffic, what is the remaining course of action? The answer is inspection, followed by manual analysis and response. If a human decides the problem is severe enough to warrant interruption, then a preventative measure is deployed.
In some places, prevention is too difficult or costly. I would like to know how one could use a network-based control mechanism to stop a host A on switch X from exploiting host B on switch X. Unless the switch itself enforces security controls, there is no way to prevent this activity. However, a sensor on switch X's SPAN port could detect and report this malicious activity.
Note that I think we will see this sort of access control move into switches. It's another question whether anyone will activate these features.
I think traffic inspection is best used at boundaries between trusted systems. Enforcement systems make sense at boundaries between trusted and untrusted systems. Note that if you don't trust individual hosts inside your organization (for whatever reason), you should enforce control on a per-host basis within the access switch.
Comments
Google for cisco pvlan and you should find some info.
If you're really looking for protocol inspection inside a switch I watched an entrasys sales presentation about this not so long back. Their newer models can embed dragon IDS/IPS. Never got to try it in a real environment but on paper it looked vaguely interesting.
(not directed to Anonymous):
Don't agree? What's an IPS, then?
One of the points of IT is automation of tasks normally done by humans, or not done at all, really. It is kind of weird to grasp, since we in IT don't like to think of the purpose of our jobs is to eliminate jobs like ours by automating things. :) But that's one line of thought.
Likewise, this fits into IPS systems. Why pay three people to monitor traffic when one system can do it faster and with a higher load? Granted, it will make mistakes and block legitimate traffic, but so could humans make mistakes. Likewise, no IT is perfect, and similar to a certain amount of downtime being absorbed andaccepted, so to can some IPS false positives.
Now, I hope that never happens, as I'd like to do these jobs before they're fully automated. :) I don't mind being replaced and moved on from this after knowing it, but much like "script kiddie" tools, I'd rather know how to do it manually before using the automated tools.
--LonerVamp
The IDS needs to audit that policy by inspecting that traffic that you can't or don't want to block at the FW and as Richard said, the analyst then takes over.
In regards to local traffic on a switch, again SPANing the VLAN is a very good way to go. A properly configured network should limit exposure of a box that has been infected or compromised by separating business units or segments (subnets).
Just my two cents.
You want to stop Host A from attacking Host B on Switch(1).
If host A and host B are in the same vlan then you need to use the VLAN ACL or VACL. Its an acl enforced in asic that gives you the access controls asked for.
Google VACL on the Cisco site.
Cisco now give its IPS products the ability to monitor the a VACL and with this you would be able to restrict access using VACL, and Monitor the allowed traffic by the acl with the IPS device so that if traffic is malicous you can modify the acl(vacl) or block the connection.
The switches store a local "policy table" that instructs the switch what the forwarding policies are for an identity (MAC/IP or Port). A policy is a "group" containing "classification filters". Classifications can be defined at Layer 2,3 or 4.
Example, I want to allow my employees to access web servers on my network - but I don't want them to provision web servers (or any servers for that matter). The sample policy set has a Policy container "Enterprise Employee" that contains the following sample set of rules: (abbreviated for brevity)
If Source Ports FTP, HTTP, SMTP, DNS, DHCP - Discard Traffic
It will forward packet with a destination socket of FTP/HTTP/SMTP/DNS/DHCP - but will discard any packet (inbound) from a normal employee host that matches the above set. It is best described as an "allow all" policy set with traffic classifiers (contained as a policy set for simple deployment) to contain/control traffic types.
This "Acceptable Use Policy" eliminates ALOT of threats. Additionally the Enterasys Matrix N-Series can track violations and alert network/security managers that a system is attemtping to violate the policy (and the switch is containing it) and the host/port match.
The policy actions can also be leveraged beyond discard to include actions that "contain to vlan" and provision quality of service.
"Contain to VLAN" is interesting as you can declare a set of IP addresses "blackholes". Instead of using 'blackhole ip' at a router deep in the network - push the blackhole ip addresses as "contain to vlan" actions. As the ARP for those IP addresses hits that first switch port (works for blackhole ip addresses that are local to the violator) - the MAC address of the offending system is added to the forwarding table of your "blackhole ip" vlan. Use a SNMP application (Enterasys NetSight Flextables are awesome for this) to poll the bridge forwarding table for the Blackhole IP vlan and you can quickly identify end-systems that are attempting scanning activity. Additionally you can program the switch to send a SNMP trap based on that classification match and automate the polling and recording process.
At Network World Interop, Enterasys Networks announced a daughtercard for the Matrix N-Series that would put a Dragon IDS/IPS inside the actual switch. This does not take a switch slot from the chassis, it is a daughtercard processor ON the switching line card. It is quite possible to put 7 Dragons in a 7-Slot chassis.
For more information, please visit www.enterasys.com or feel free to email me. We have written some really killer applications of this technology and have a lot of very large clients running networks north of 50,000 ports using policy to control some of the wildest networks - large universities. We have a university of 65,000 nodes running securely with a staff a third the size of their competitors.
ROSI possible? Absolutely.
While I was configuring the above policies at iLabs HotStage for the NAC interoperability testing - I deployed a full set of policies on the switches containing most common threats in less than 5 minutes. We've been delivering this functionality since 1998 and have truly mastered protocol containment in a traditional layer 2 environment. Heck - we can even "augment" 3rd party networks by masking these policies to a MAC or IP on the N-Series platform if it is placed upstream (distribution layer) of a 3rd party platform.
Great list - Richard is one of my favorite authors.
Best to all!
Mark
Mark Townsend
Director Security Technologies
Enterasys Networks
markt@enterasys.com