The key here is that network IDS is low-latency.  There are solutions for SPAM that are established and proven.  I'll let them do their jobs, because they can take their time to parse the email, consult spamhaus, etc...  There is not a better solution for detecting the delivery of exploits, that is the job of an IDS.  SPAM can lead you to an attack, or to a longer *****, but it isn't, in itself an attack.<div>
<br>I agree there is a ton of metadata on the network that is incredibly useful both for correlation and forensics (see intel nuggets on Razorback).  But again, that is parsing known protocols that are well formed.  Easy at speed.<br>
<br><div class="gmail_quote">On Fri, Feb 11, 2011 at 9:55 AM, Seth Hall <span dir="ltr"><<a href="mailto:seth@...14966...">seth@...14966...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Feb 10, 2011, at 9:55 AM, Matt Olney wrote:<br>
<br>
> Also, SPAM isn't an IDS issue, at least from my point of view.  I worry about malicious, not asinine.<br>
<br>
</div>Ouch, seriously?  In my opinion, if it goes over the network it's an IDS issue.  Sometimes it's incredible how many little, seemingly inconsequential bits of information will add up over time to mean something much different and much more important.  Maybe the remote IP address sending spam doesn't mean much for an incident response team by itself, but if that IP address logs into some local box over SSH that would be worth looking into.<br>

<font color="#888888"><br>
  .Seth</font></blockquote></div><br></div>