Re: IPS technology question.

[Pukhraj Singh <pukhraj.singh () gmail com>]

The Intrusion Prevention technology is in quite an exciting phase. A
lot of product based start-ups are implementing very novel concepts in
order to produce 'real' Intrusion Prevention Systems. I use the term
'real' because of my general unsatisfaction with the way the current
leading vendors are popularizing their not-so-good IPSes. Most of
these devices aren't even worthy of being called an IPS, they are
unreal, hyped up regex engines on nitro.

Regarding your question about how to judge and rate IPSes, I think, it
is not a quantitative issue (as you asked for surveys and statistics).
It is more of a qualitative issue. There are certain factors by which
you can judge the effectiveness of an IPS, I will mention a few:

The first and foremost is the core engine. The previous methods of
customizing and tweaking some freely-available softwares and making
the whole device upon it is extinct. Most of the these devices start
right from the customization of the kernel code (especially protocol
stack), further moving up to produce APIs and hooks for developers to
effectively work at different abstract layers like correlation engine,
parsers, TCP/IP, application layer, reporting engine. Do note, that
producing ASIC and FPGA, are not generally on the top priority list as
this really comes in the later phases when the product already has
some market hold. Secondly, there are many alternatives which can be
used instead of producing the costly and painstaking FPGA-based
appliances (like tying them u with load balancers which can give up to
2.5 Gigs of speed). So stability at the core is a must.

Moving up, protocol decoding is also seeing some interesting trends.
This is the most crucial part of an IPS. Most of the time and effort
is spent to make this part of IPS stable, effective, efficient and
precise. I think almost all the IPSes are decoding the protocol
(application layer ones) primarily, sometimes called
'deep-inspection'. There are a lot of issues to be taken into
consideration like the protocol decoding must not only be concurrent
to RFC standards but should also be compliant with the application it
is protecting (as the way application decodes the protocol and the way
RFC suggests don't really match in most cases). Also the difference
varies from application to application (IIS, Apache). For closed,
propriety protocols lot of hit-and-trial, reverse engineering and
checking is required. Also different types of encodings (%u, UTF),
formats (RPC, RPC over HTTP) should be taken care of. In fact, almost
all attacks for bypassing these devices are perpetrated at this layer,
the decoding layer; where there is a big probability that the IPS is
not decoding the protocol properly
(http://seclists.org/lists/focus-ids/2004/Dec/0092.html).

Now comes another important aspect, the prevention part. Most IPS, add
the word prevention, namesake. In fact, these abrupt prevention
routines (and decoding routines) lead to a lot of false positives and
false negatives. There should be some logic behind prevention. Like if
they are doing the normalization of data then the normalization must
sound logical and it should work!

Finally, comes another important factor, the knowledge base. IPSes
must be ahead of hackers and exploits at every point. The convergence
time, in which the vulnerability is released and the signatures are
available to IPS customers should be minimum and pre-decided. In fact,
there should be a 0-day crack team which should constantly lookout of
undisclosed vulnerabilities, reverse engineering of new patches coming
out and producing and distributing the fixes and normalization
routines ASAP. A good QA team and process is a must. The focus should
be on vulnerability and not the exploit.

Finally, the only thing left is the interface. The administrator must
have a handy, flexible, secure (of-course) interface so that he can
customize the profiles which he want to run depending on the servers
he want to protect. There should be alternate strategies for crashes,
failures, power breakdowns so that if IPS goes down, the whole network
should not suffer.

These were some of factual traits for judging IPSes. I know, it sounds
like a developer-oriented perspective. You must be looking out for
some crude relative statistics. Believe me, it is pretty easy to
assess the appliance on these factors too, doesn't require much skill,
just some close observation and time.

Pukhraj Singh
SigInt Network Defense
www.sigint.co.in


On 8/23/05, snort user <snort.user () gmail com> wrote:
> Greetings.
>
> What percentage of the IPS systems are out there, which does not use
> co-processors/FPGA etc..
>
>  What percentage of the IPS systems depend on firewalls like iptables
> and ip filter ?
>
> I am just trying to get an idea of what is the state of art in the IPS
> technology space.
>
> Any information is appreciated.
>
> Thanks
>
> ------------------------------------------------------------------------
> Test Your IDS
>
> Is your IDS deployed correctly?
> Find out quickly and easily by testing it
> with real-world attacks from CORE IMPACT.
> Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
> to learn more.
> ------------------------------------------------------------------------

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------