Re: [Emerging-Sigs] sensitive data pre-processor

[Joel Esler <jesler () sourcefire com>]

I've had the SDP successfully deployed in a number of areas.

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.

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.

So your milage may vary as far as the SDP is concerned.

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.)

Joel

On Wed, Sep 29, 2010 at 1:35 PM, Tilley, Brad <rtilley () radford edu> wrote:

> > is anyone else getting FPs with the sensitive data pre-processor?
>
> Yes, but that is to be expected.
>
> > every single firing i've seen of the sensitive data rules has been a
> > false
> > positive and always apparently related to the serialization numbers
> > used in web
> > forms on forums and social networking sites...
>
> Same here, but again, that should not be surprising.
>
> > currently i have the SDF email addresses and social security numbers
> > (w/out
> > dashes) disabled... i've had numerous firings on the social security
> > numbers (w/
> > dashes) rule, too, but have not yet disabled it...
> >
> > it is especially telling when the SSN rules fire on sites that have no
> > SSN data
> > on them or those that do but it has never been given...
>
> Basically, *any* nine digit number is a SSN (with a few notable
> exceptions)... some day 123-45-6789 will be issued in NY State.
> Go here to test numbers (Only enter fake numbers or generated test data):
> http://16systems.com/numbers
>
> 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).
>
> 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.
>
> Brad
>
>
>
>
>
> > can the SDF decode encoded strings and may it possibly be detecting
> > sensitive
> > data in there??
>
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs () emergingthreats net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and
> Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users