Re: PCI Compliance Scope

[Danux <danuxx () gmail com>]

Excellent reference and explanation, now it is pretty clear for me.

Thanks all!!

On Fri, Nov 13, 2009 at 10:21 AM, Jason Hurst <Jason.Hurst () pandarg com> wrote:
> Hi Danux and all,
>
> I think I should be able to shed some light on this.
>
> Your Log Management server is in scope, but only your log management server, not all devices that connect to it, with 
> some caveats.
>
> 1) First off, why is your log management device in scope?
>
> The reason for this is that your log management tool is the device that you would use to make a determination if 
> credit card data had been tampered with. Without logs being accurate, you cannot accurately conclude whether or not 
> your credit card data is had a breach of confidentiality or integrity. It is important to remember that for the 
> purpose of scope determination is that not all bad guys are considered to be on the outside of your organization, and 
> you must also adequately protect your equipment from internal tampering.
> (On a related note, if you do not secure your logs in a legally recognized fashion, such as through cryptographic 
> hashes, they would not be admissible in a court of law, even if you did catch someone)
>
> For the purpose of your organization, your log management server will be in scope. I would highly recommend that at 
> this point you do not spend any more of your energy trying to find an argument as to why it is not, as that would 
> probably be a waste of your time.
>
> 2) Secondly, why, if your log management server is in-scope, are the other devices delivering logs to it not in scope?
>
> A lot of this does depend on the configuration of your network, (hence the caveats) but to keep it simple, think of 
> your log management device as being its own DMZ. It can access your in-scope environment, it can access your 
> out-of-scope environment, but your out-of-scope environment cannot access your in-scope environment. It IS the 
> separation. As long as your in-scope stores and your in-scope log management device are adequately secured, you do 
> not have to consider the other devices.
>
> 3) The caveats.
>
> You should certainly ensure that you have adequate network segmentation to treat your log management server as its 
> own DMZ, that it has be secured using recognized standards, such as the CIS, and that whatever software you are using 
> for log management also supports high security, preferably through a combination of ACL, Encryption and hashing.
>
> 4) Reference Material:
>
> The ISACA download section. The ISACA is the certifying authority for most auditors, it is a very good place to start 
> to understanding what they are looking for. Many of their publications are free, however some require an ISACA 
> membership, and some you must purchase.
> http://www.isaca.org/Template.cfm?Section=Downloads3&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=63&ContentID=13742
>
> NIST guide to log management. (You probably already have this, but I thought I would include it anyways.)
> http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
>
> Hope this helps!
>
> Jason Hurst
> Sr. Network Security Administrator
> Panda Restaurant Group
> jason.hurst () pandarg com
> Please consider the environment before printing this email
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Danux
> Sent: Thursday, November 12, 2009 2:18 PM
> To: pen-test () securityfocus com
> Subject: Re: PCI Compliance Scope
>
> Thanks all for your feedback,
>
> I will clarify the most common questions you asked:
>
> a) The Log Management server is a receiver so it is not able to reach
> PCI Assets.
> b) The Log Management server does not store PII/CC data.
>
> It seems like 80% of the audience thinks that if I am not storing
> PII/CC data in the Log Server and not direct access (push) to PCI
> assets then it should be out of scope.
>
> I asked the PCI Auditor that in my  opinion the PCI goal was to
> protect CC data and since my Log Server is not able to reach PCI
> assets then it was out of scope.
> The PCI Auditor said exactly what David Glosser mentioned above, The
> goal in this point is to protect the Log Server from tampering.
>
> I totally disagree with that because I think PCI goal is to protect CC
> data and if no PII/CC is store in log server then it does not matter
> if someone is tampering it.
> Someone can tell me whether by getting usernames from log files you
> are gonna be able to bypass firewall to connect to PCI assets and or
> get passwords automatically and or steal/decrypt CC data? All this
> requires extra effort, usernames are not even considered PII since is
> something PUBLIC.
>
> Now, if the goal is to protect Log files then as i mentioned at the
> beginning of this conversation, all assets pushing info to Log server
> are in scope too!! because each one can reach it and therefore try to
> compromise it.
>
> CONCLUSION:
>
> Lets think as Auditors, if I want to convince PCI Auditor about
> putting my Log Server out of scope, I need trust resources. Do you
> have any documentation from trusted sources like NIST, Garner, so on
> where explains how to deal with this Scenario?
>
> Thanks all once again.
>
> I promise to let you all know the result of this point to know the
> real way in a PCI perspective to deal with.
>
> On Thu, Nov 12, 2009 at 3:34 PM, Eric Milam <emilam () coretechsg com> wrote:
> > Its not my decision, last I checked I don't think the PCI Council allowed it
> > as the only form of separation.
> >
> >
> >
> >
> > Tracy Reed wrote:
> > > On Thu, Nov 12, 2009 at 12:42:35PM -0800, Eric Milam spake thusly:
> > >
> > > > Basically the fear are base camps from which to launch an attack.
> > > > As Erin stated below, if there are measures in place (not just
> > > > vlans) to prevent access from the log machine to the Card Holder
> > > > data environment then it may be that the device will be out of
> > > > scope.
> > >
> > > Why not just VLANs? Do we not trust VLANs or are we worried about VLAN
> > > misconfiguration? Or switch compromise? Cisco commissioned a study by
> > > @Stake (IIRC) which made a pretty good case for VLAN security. Of
> > > course, that may just be Cisco getting the results it paid for. But it
> > > seemed reasonable to me.
>
>
>
> --
> Daniel Regalado aka Danux
> Hacker Wanna Be from Nezahualcoyotl
>
> www.macula-group.com
>
> ------------------------------------------------------------------------
> This list is sponsored by: Information Assurance Certification Review Board
>
> Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
> and CEPT certs require a full practical examination in order to become certified.
>
> http://www.iacertification.org
> ------------------------------------------------------------------------



-- 
Daniel Regalado aka Danux
Hacker Wanna Be from Nezahualcoyotl

www.macula-group.com

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified.

http://www.iacertification.org
------------------------------------------------------------------------