Re: Using snort in an PCI DSS environment

[John Millican <john () millican us>]

On 11/20/2013 11:34 AM, elof () sentor se wrote:
> 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



Sorry for the previous top posting, that is what happens when I think
and type at the same time.

What we did was convince and prove that all data was encrypted in
transit.  Since we had some control over what was sent to us from
terminals and such we able to ensure that data was encrypted in transit
when on the public Internet and since snort was on the edge of our
network (WAN side only) it never actually saw any unencrypted card data.
 Internally was a tightly controlled application only LAN where we could
easily prove.
JohnM




------------------------------------------------------------------------------
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!