Focus on IDS
Reputation based IPS/IDS - Cisco's tested Aug 11 2009 03:49PM
Joel Snyder (Joel Snyder Opus1 COM) (1 replies)
Re: Reputation based IPS/IDS - Cisco's tested Aug 22 2009 05:34PM
Frank Knobbe (frank knobbe us) (1 replies)
Re: Reputation based IPS/IDS - Cisco's tested Aug 24 2009 04:36PM
Gautam Singaraju (gautam singaraju gmail com)
Wanted to add something to the discussion as well.

We performed an experiment based on email reputation as a part of our
research efforts (http://isr.uncc.edu/repuscore for the results).
After a few months, we noticed a brute-force attack on the website.

Based on the email reputation computed we could identify a small
fraction of IP addresses from which the attack occurred (both good and
bad: which is the good part of email reputation). RBLs were a
little-bit more accurate for bad IP addresses; but it was still a
smaller fraction than what I had expected to see. A large percentage
of the attacks come from IP addresses we have no information about.

I believe, the correlation would help in creating two groups of
alerts: 1. the alerts we know reputation about and 2. might be to use
reputation to identify those we know and those we do not know about.
Clearly, correlating with reputation without properly presenting this
information to the user might not be sufficient.
---
Gautam Singaraju

On Sat, Aug 22, 2009 at 1:34 PM, Frank Knobbe<frank (at) knobbe (dot) us [email concealed]> wrote:
> On Tue, 2009-08-11 at 17:49 +0200, Joel Snyder wrote:
>> Some of you may remember our discussion back in November, 2008 about
>> using reputation services in IPS.  (search for subject line "Email
>> reputation for inout to IDSs?" if you want to read it).
>
>
> From the article:
> "This basic use of reputation filters isn't new, but what's interesting
> is that Cisco will use this reputation data to change the Risk Rating of
> security events identified by the IPS. In other words, an event linked
> to a 'bad' IP address will result in an even higher Risk Rating."
>
>
> Isn't this backwards? The risk to a system of an attack coming from an
> known attacker compared to an unknown attacker is the same. Matter the
> fact, I'd like to argue the opposite. Since the known attacker has
> already been identified (and can be blocked), the Risk Rating of the
> alert for that address should be lower. Unknown attackers should receive
> a high Risk Rating so they stand out and can be addressed first (like
> that laptop in the article's example).
>
> Now, I understand that the *assurance* of the alert is higher, since the
> attacker has already been verified as hostile, so the likelihood of a
> false positive from that address is lower. But I think classifying the
> known attackers as high risk so the user focuses on those first is a
> misguided step in the wrong direction. I can already envision the
> evasion scenario: Flood your target with SQL injections attacks through
> known open proxies (so they receive a high Risk Rating), and slip in the
> real attack from an unknown IP (classified now as ... not-so-high risk).
> Which would you be more concerned about?
>
> IP intelligence within the IDS console is of course of great benefit.
> (we've been doing this for years. Then again, we've been using IP
> reputation and blocking known evil IP's in a distributed fashion for
> years as well...). Any IP intel for the analyst in the console is a good
> thing. I'm just not sure that *interpreting* that IP intel on behalf of
> the analyst is the right thing to do.
>
> Thoughts?
>
> Regards,
> 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.
>
>

-----------------------------------------------------------------
Securing Your Online Data Transfer with SSL.
A guide to understanding SSL certificates, how they operate and their application. By making use of an SSL certificate on your web server, you can securely collect sensitive information online, and increase business by giving your customers confidence that their transactions are safe.
http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a
17f194

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus