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=/TaggedPag
e/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 (at) pandarg (dot) com [email concealed]
Please consider the environment before printing this email

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Danux
Sent: Thursday, November 12, 2009 2:18 PM
To: pen-test (at) securityfocus (dot) com [email concealed]
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 (at) coretechsg (dot) com [email concealed]> 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
------------------------------------------------------------------------

------------------------------------------------------------------------

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

[ reply ]