Re: Email reputation for inout to IDSs?

["Sanjay R" <2sanjayr () gmail com>]

agreed  that such an approach may be useful for Managers, specially
for Alert filtering. But i think the question was to use reputation to
decide the degree of scanning the traffic by an IDS => IDS will scan
the packets based on its reputation. I want to emphasis here that
there is fundamental difference between an firewall (with static ACLs)
and IDS/IPS. IDS/IPS alerts when it actually SEEs the attack, whereas
a firewall (in its most general form) can be configured to block
packets according to predefined IPs/URLs etc. Remember that in case of
NAT, the same IP can be used by malicious users as well as by good
users, but it will always be blocked by firewall. IDS/IPS will  not do
so, at least in theory. Of course, as a product, one can always
advertise it as advanced correlation technology to reduce false
positives etc. In case of gateway AV, URl filtering makes sense as
users are accessing them and they are known to be malicious. I think,
in this case, traffic does not even reached the engine as it is
blocked.

hope I am clear..but its interesting to have others views.
-Sanjay

On Wed, Nov 26, 2008 at 9:07 PM, Joel Snyder <Joel.Snyder () opus1 com> wrote:
>  There are a few IPS/IDS solutions out there utilizing email reputation
> > as part of their solutions, and they primarily get their strength from a
> > centralized managed db on the part of the vendor supplying the solution.
>
> I haven't seen this actually happening; do you have specific products in
> mind?  Other than 'intention,' it doesn't seem to have been rolled out yet.
>
> In general, though, I agree with you: this is great stuff... potentially.
>
> Incorporating reputation services (not just email, but web as well) into
> IDPs is an outstanding way to help provide the IDP with additional
> information that might help it to do a better job.
>
> In the simplest case, this information could be correlated at the console so
> that IDS-ish activity can be prioritized by 'known bad actors.'  The
> prevalent behavior of many network managers in applying bias to their
> firewalls (e.g., PIX shun or Check Point SAM) based on past bad behavior is
> an example of why this would be successful and useful.
>
> In other words, I am MUCH more interested in an alert if it comes from
> someone with a known bad reputation.  These are more likely to require
> action on the part of the network manager, or at least to be 'interesting'
> in the sense of understanding a threat pattern or ongoing robot-based
> attack.  That alone should help to bubble up alerts in the console of the
> IDS.
>
> For example, correlating the Spamhaus PBL (policy block list, essentially a
> list of IPs which have been defined by their owners as 'these guys should
> never be sending mail directly') with IDS alerts would be outstanding
> information, because anyone on the PBL generating a alert is likely to be
> bot-infected or intentionally malicious.  What you do with that... I don't
> know directly, but anything that can help to provide greater context in IDS
> alerts is obviously of value.
>
> In a more complex case, the presence of an IP on a reputation service
> (again, email or web, since they are merging with the significant vendors of
> these services) could also affect the behavior of an IDP when it comes to
> actually dropping or resetting connections.  This is obviously harder to
> manage and now begins to tread on the territory of other products.
>
> For example, a standard Web Security Gateway (pick Cisco's WSA as an
> example, but there are a dozen of these products) already is blocking
> connections from end-user clients to bad-reputation web sites.  If the IPS
> started doing the same, this could either be a defense-in-depth strategy
> (two reputation services are better than one?) or might be useful in an
> environment where the enterprise did not have a Web Security Gateway but
> wanted to fold that functionality into their existing IPS.  See, for
> example, the build-up of UTM firewalls as a precedent for this.
>
> I think that it seems obvious that, given the level of sophistication of
> existing IDP detection engines, anything that we can do to give them "more
> intelligence" is a step in the right direction.
>
> This could happen at detection-time or at analysis-time, as I've mentioned
> above--and these are certainly not the only places where it could be useful.
>
> It seems to me that given the purchase of Ironport (with their Senderbase
> web/email reputation service) by Cisco and the purchase of Ciphertrust by
> Secure Computing by McAfee (with their TrustedSender web/email reputation
> service) presages the integration of these technologies into IDP products.
>  Whether folks like Sourcefire will be able to forge (useful) alliances with
> semi-open-source products like Spamhaus or commercial products like
> Commtouch remains to be seen, but certainly if/when Cisco and McAfee start
> pushing integration, there will be pressure on for everyone to start folding
> this in.
>
> jms
>
>
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One       Phone: +1 520 324 0494
> jms () Opus1 COM                http://www.opus1.com/jms



-- 
Computer Security Learner

------------------------------------------------------------------------
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.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------