[Discussion] Features

[th3 m0nq]

<snip>
As Robert and Martin eluded in an other
thread, any sort of correlation and IP analysis, scoring,
severity-bumping, etc, is best done in the analysis or portal engine.
</snip>

I agree here, but does next generation mean an advanced version of
snort?  Does next generation mean an evolution in terms of thinking
about IDS/IPS?  Do we leave things as they are and say that there
exist NIDs, DIDs, HIDs, and they don't form a cohesive immune system
for my network?  I would like to see an evolution of such technologies
be more biological in nature.

<snip>
I don't think any existing detection engine of an IDS is the proper place.
But perhaps a parallel engine that collects network stream data and does
matching on hostile IP's, and then checks (perhaps by packet/session
timestamp) if the IDS did produce an alert in a recent time window
(since the session-IP-eval-engine will surely lag behind)
</snip>

I am with you here as well.  Why is the parallel engine not part of
the IDS?  Why should next generation IDS mean a better snort?  Why
can't it mean a better way of looking at network security?
http://en.wikipedia.org/wiki/Immune_system#Layered_defense  What about
an all encompassing IDS/IPS _system_?

I am not saying I have the answers, or something similar to an expert
system is the answer.  I am saying I think the issue should be looked
at as we dump the current way we do things in a temporary holding
cell, and think in evolutionary terms.  This makes 4 cents ;-).


Adrian








On Sat, Oct 18, 2008 at 5:01 PM, Frank Knobbe <frank at knobbe.us> wrote:
> On Sat, 2008-10-18 at 16:28 -0500, th3 m0nq wrote:
>> [..] I think there is
>> room, at minimum, to have packets that do not necessarily trigger a
>> rule "flagged" in some way in an IDS.  This could be implemented as a
>> plug-in component of the system.  This may be way outside of the scope
>> of what you guys are looking at, but that's my 2 cents.
>
> Receiving alerts (with session content) on IP's that don't trip existing
> signatures, but are present in a hostile-IP list, is a good idea (for
> example, to detect new evasion techniques of existing badware).
>
> However, I don't think the sensor is the proper place for that due to
> the immense IP-matching workload that would have to occur on a
> per-packet or per-session basis (remember, we're talking at least tens
> of thousands hostile IP's). As Robert and Martin eluded in an other
> thread, any sort of correlation and IP analysis, scoring,
> severity-bumping, etc, is best done in the analysis or portal engine.
> (We do those things in our shop as well, with back-end scripts and our
> portal).
>
> While you can make decisions on the IP "badness value" for analysis, you
> would of course miss the content of the IP not receiving an alert. I
> don't think any existing detection engine of an IDS is the proper place.
> But perhaps a parallel engine that collects network stream data and does
> matching on hostile IP's, and then checks (perhaps by packet/session
> timestamp) if the IDS did produce an alert in a recent time window
> (since the session-IP-eval-engine will surely lag behind). That check
> would probably be best done against the IDS/portal database. A simple
> bpf filter with hostile 20,000+ IP's to capture content will probably
> not cut it :)
>
> -Frank
>
>
> --
> It is said that the Internet is a public utility. As such, it is best
> compared to a sewer. A big, fat pipe with a bunch of crap sloshing
> against your ports.
>
>