Re: Using snort in an PCI DSS environment

[elof () sentor se]

Thanks, John.

As I suspected then.
Damn those loose definitions.

If I enable the sensitive data masking option, that is an Action of mine 
to try to prevent clear text card numbers to be stored, however I know the 
action has no effect at all to what I was describing.
The question is:
How long and deep must I protect myself against clear text passwords from 
accidentally being logged before the QSA approve?

In the LAN where I'm sniffing, no clear text card numbers should exist in 
the first place, so the whole discussion is kind of messed up.
I find it hard to protect myself from any kind of what-if-scenarios. What 
if the traffic isn't encrypted so there are plain text card numbers? What 
if a rule matches a packet, and this packet just happen to also have a 
card number in clear text in it?


So what was you solution? Did you encrypt the snort logs or did the 
QSA accept that everything was encrypted over the LAN?

(
Sure, building a pre-preprocessor that anonymizes all possible card 
numbers in all frames in all protocols will keep me in the clear from PCI 
compliance demands, but performance-wise it would be really bad for the 
sensor. Not to mention that such anonymization could modify random data that 
just happen to match the Luhn algorithm and thereby cripple the ordinary 
IDS detection.
)

/Elof



On Wed, 20 Nov 2013, John Millican wrote:

> Just worked with a QSA on a PCI DSS audit, Although IANAL! YMMV.
>
> We did use snort as part of our IDS/IPS scheme(pfSense install) and we
> were told that any time there is a chance that a card number could be
> captured it was our responsibility to prevent that.  There are
> remediation policies that "might" allow you to get around this but it is
> highly doubtful that they would stand up in court if it ever came to that.
>
> The first issue that comes to mind though is that anytime track data is
> in transit on a public network it should be encrypted so snort should
> never even see that there is a card number (or any other track data) in
> the data stream.  On your internal network this requirement is not as
> clear, but we kept all data encrypted until it was actually needed to be
> used by the application and then re encrypted immediately afterward.
>
> One of the very first things our QSA did was scan every system in scope
> for card numbers, and other data, that should not be stored in the clear.
>
> PCI does not "force" you to encrypt the entire HDD, you can encrypt only
> the protected data and be in compliance.  It is your choice which method
> best suits you environment.
>
> Regards,
> JohnM
>
> On 11/20/2013 09:03 AM, elof () sentor se wrote:
> > Anyone here using a snort sensor in an PCI environment?
> >
> > I'm wondering about PCI compliance regarding logging of potential card
> > numbers...
> >
> >
> > Say I have a snort sensor in a PCI environment.
> > Nothing in the sensor is configured to detect and log card numbers on
> > purpose. Only normal IDS-rules are enabled.
> >
> > Do PCI still force me to encrypt the harddrive just because there is a
> > possibility that a card number *could* accidentally be logged?
> >
> >
> > What do your QSA say?
> >
> > Yes, the sensor's HDD is in scope and must be encrypted.
> >
> > or
> >
> > No, a few potential card numbers, logged by accident, does not count.
> > It's like saying you need to encrypt your mailserver's harddrive just
> > because someone can e-mail you card numbers even though you haven't asked
> > for them.
> >
> > /Elof
> >
> > ------------------------------------------------------------------------------
> > Shape the Mobile Experience: Free Subscription
> > Software experts and developers: Be at the forefront of tech innovation.
> > Intel(R) Software Adrenaline delivers strategic insight and game-changing
> > conversations that shape the rapidly evolving mobile landscape. Sign up now.
> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > 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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> >
> > Please visit http://blog.snort.org to stay current on all the latest Snort news!
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> 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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>
> Please visit http://blog.snort.org to stay current on all the latest Snort news!

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!