RE: Changes in IDS Companies?

["Ramesh Gupta" <ramesh () intruvert com>]

> > that problem from the start. So what if they claim to process ~2 Gbps 
> > if
> > they have immature intrusion analysis mechanisms?  Until I see some IPS
> > systems undergo some rigorous testing (like Neohapsis OSEC) to separate
> > the hype from the reality, I remain skeptical. Only RealSecure &
Intruvert
> > have been certified to date, but not the RS Guard product.  
> > IntruShield
is 
> > an inline IDS, but is quite expensive (~$100K).



I would like to clarify that IntruVert sells two products:

1. IntruShield 4000 : Supports 4 Gigabit Ethernet interfaces to process 
traffic from 4 SPAN ports, monitor traffic on 2 full-duplex Gigabit Ethernet 
links using GE taps or be deployed in-line on two full-duplex Gigabit 
Ethernet links. The deployment modes can be mixed and matched as well, i.e. 
monitor 2 GE SPAN ports and be in-line on a full-duplex GE link. The total 
traffic that can be processed is up to 2 Gbps. The detection mechanisms 
include Signature Detection, Anomaly Detection (protocol, statistical and
Application) and Denial of Service detection. Offering all of these 
capabilities, the list price of the I-4000 is $99,995.

2. IntruShield 2600: Supports 6 10/100 Ethernet interfaces (has built-in
taps) and 2 Gigabit Ethernet Interfaces supporting SPAN, Tap and In-line 
modes with the ability to mix and match deployment modes. I-2600 can process 
up to 600 mbps of traffic. The detection mechanisms include Signature 
Detection, Anomaly Detection (protocol, statistical and Application) and 
Denial of Service detection. Offering all of these capabilities, the list 
price of the I-2600 is $34,995.

So on a price/port basis, it costs a whole lot less.



I believe some of the key requirements of an In-line IDS (IPS) include:


1. Unquestionable accuracy

a) Reduction of false positives through stateful protocol analysis and high 
quality signatures that look for as many strings in as many protocol fields 
as possible

b) Anti-evasion (able to deal with layer 3-7 evasion)

c) Ability to deal with mutated attacks

d) Accuracy of buffer overflow detection

e) Accuracy of Anomaly Detection: Using self-learning to learn "normal" 
behavior and then trigger on anomalies instead of triggering anomalies based 
on simple thresholds 

This capability can be easily verified by a test lab such as Neohapsis (OSEC 
tests), NSS, Miercom, etc. Verification of reduction of false positives can 
also be done by end customers with real-world traffic.  


2. In-line operation

a) Type and number of interfaces (a single interface IDS can't sit in-line)

b) Compatibility with all layer 1, 2, 3 and 4 devices such as repeaters, 
bridges, switches, routers, firewalls and load balancers


3. Packet processing latency similar to other networking devices such as 
firewalls and load balancers. This can be verified by customers using 
simple tools such as Ping while the IPS is processing real-world traffic.


4. Reliability (uptime): Should be as reliable as other in-line networking 
devices such as routers, firewalls and load balancers. Customers can easily 
verify the reliability by installing the device in real-world traffic and 
observing the down-time. Before installing the device in-line, customers can 
also verify the reliability by deploying the product in a passive mode
(monitoring traffic from a SPAN port or taps) and observing its
stability before deploying the product in-line. An in-line IDS
must deal with all possible corner cases effectively and this should
be made part of its design and not an afterthought.


5. Fine-grained granularity in allowing the customer to decide which 
attacks get blocked and which don't. Customer should be able to configure 
blocking per attack per policy and customer should be able to create and 
assign multiple policies to a single sensor or a single interface. Customer 
should be able to segment the traffic on a single physical interface into 
multiple logical sub-interfaces using CIDR blocks or VLAN tags and assign a 
different policy to each sub-interface. 

 
6. Performance that meets the needs of the customer network, i.e. not 
dropping packets under peak loads in the specific environment in which it is 
deployed. Should scale to meet the traffic load and the number of expected 
signatures 3 years or longer from now. Performance should be 
measured using real-world traffic characteristics. For example, if one is 
using HTTP to measure performance, I would suggest that they use:

1. HTTP 1.1
2. 4-5 HTTP GET requests per TCP flow with
3. A real-world URL and Internet Explorer HTTP headers in the GET request
4. Average HTTP response of roughly 4000 bytes

We have verified this average HTTP traffic characteristic on many customer 
Networks as well as by analyzing popular web sites. Many products state 
their performance using average HTTP response sizes of 10K or 20K bytes which 
is easy on the IDS/IPS, but is not reflective of the real-world traffic mix.

Again, performance can be easily verified by test labs using real-world 
traffic characteristics such as the ones stated above.  



There is a lot of FUD regarding IPS  and justifiably so as it 
is an emerging and disruptive technology. Will Intrusion Prevention become
a reality? I believe it will... Is it mainstream today? NO. As has been said 
earlier, Intrusion Prevention is not a new idea. However, there are some new 
intrusion detection and prevention products that could be catalysts for 
increased adoption. I believe that intrusion prevention will follow the 
technology adoption cycle that many products do. There are early adopters, 
early majority etc. etc. Just like in the adoption of firewalls, VPNs etc. 

An  earlier email from Andrew Plato  said he  has *many* customers with 
inline intrusion prevention deployments for a period of time. At IntruVert, 
we have customers who also have deployed the IntruShield inline and are using 
active blocking today. 

I believe that if a product meets the requirements stated above, it will
overcome these concerns which are   natural for any emerging and 
discontinuous technology.


Best regards,

Ramesh Gupta
Founder, VP Engineering
Intruvert Networks Inc.