Home page logo

pen-test logo Penetration Testing mailing list archives

Re: PCI Compliance Scope
From: "David M. Zendzian" <dmz () dmzs com>
Date: Thu, 12 Nov 2009 22:07:16 -0500

It is not always about compromising the cardholder data but ensuring the
security of the audit log behind all servers & services that
store/transmit/process cardholder data.

It is a tool used for "after the fact" analysis to determine what
happened and where.

Also, if you read through the pci-dss you will see logging mentioned
throughout.  Your auditor is going to have to take samples of your
systems and should (i hope) ask for samples & validation that all those
logs are stored offline (central log server), archived in accordance
with policy & legal requirements, restricted access and monitored daily
for security activities.

One thing I also dig into is to be sure that all cardholder services are
logged.  Most people just stop at syslog on all services, but that
normally does not get the application logs, database logs, ids and other
traditional stand-alone services which are all also PCI services and
need to be logged and monitored accordingly.

Again, good luck!


Danux wrote:
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.


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

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.

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. 


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]