I've had the SDP successfully deployed in a number of areas.<div><br></div><div>The reality of the situation is, like Brad said below, it detects strings of numbers.  Yes, there is some intelligence to the format of the numbers and how they start and end and things like that, but there are just basically strings of numbers.</div>
<div><br></div><div>I've seen HTTP cookies, url's, webpages, etc fire on the SDP.  I've also seen SSNs, credit cards, and lots and lots of legit stuff trigger on them as well.</div><div><br></div><div>So your milage may vary as far as the SDP is concerned.  </div>
<div><br></div><div>Example:  Where I've gotten my most value for the product is in a clean (no-web-traffic environment) where the customer was not aware of the content of traffic, and come to find out the traffic as laden with SSNs and credit cards (much to the behest of the customer.)</div>
<div><br></div><div>Joel</div><div><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 1:35 PM, Tilley, Brad <span dir="ltr"><<a href="mailto:rtilley@...14863...">rtilley@...14863...</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">> is anyone else getting FPs with the sensitive data pre-processor?<br>
<br>
</div>Yes, but that is to be expected.<br>
<div class="im"><br>
> every single firing i've seen of the sensitive data rules has been a<br>
> false<br>
> positive and always apparently related to the serialization numbers<br>
> used in web<br>
> forms on forums and social networking sites...<br>
<br>
</div>Same here, but again, that should not be surprising.<br>
<div class="im"><br>
> currently i have the SDF email addresses and social security numbers<br>
> (w/out<br>
> dashes) disabled... i've had numerous firings on the social security<br>
> numbers (w/<br>
> dashes) rule, too, but have not yet disabled it...<br>
><br>
> it is especially telling when the SSN rules fire on sites that have no<br>
> SSN data<br>
> on them or those that do but it has never been given...<br>
<br>
</div>Basically, *any* nine digit number is a SSN (with a few notable exceptions)... some day 123-45-6789 will be issued in NY State.<br>
Go here to test numbers (Only enter fake numbers or generated test data): <a href="http://16systems.com/numbers" target="_blank">http://16systems.com/numbers</a><br>
<br>
So let's say that NY issued 123-45-6789 to John Doe. You may see 123-45-6789 in lot's of places, and that string is indeed a valid SSN, but not in the context of a website that has nothing (at all) to do with John Doe. Snort isn't doing context validation. It does not know that John Doe's name is not on the website, it just sees 123-45-6789 and triggers (as it should).<br>

<br>
I wrote Find_SSNs/CCNs (years ago) for Virginia Tech. I'm used to dealing with this sort of thing. At best, you'll have 90+ percent false positives when dealing with US SSNs. Now, what *did* surprise me about Snort's preprocessor was the FP rate on CCNs, that was way more than I've dealt with. My experience with SSNs and CCNs has always been that CCN detection is far, far more accurate, but that is not the case with the new preprocessor.<br>

<font color="#888888"><br>
Brad<br>
</font><div class="im"><br>
<br>
<br>
<br>
<br>
> can the SDF decode encoded strings and may it possibly be detecting<br>
> sensitive<br>
> data in there??<br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
Emerging-sigs mailing list<br>
<a href="mailto:Emerging-sigs@...14333...">Emerging-sigs@...14333...</a><br>
<a href="http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs" target="_blank">http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs</a><br>
<br>
Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards<br>
<a href="http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html" target="_blank">http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html</a><br>
</div></div></blockquote></div><br></div>