Scope Creep?

[MktgMind]

My department supports our employer's senior executives' desktop and laptop systems. The executives have an exclusive VPN that is well protected from vulnerability but simplifies login to our intranet and access to email and internal web sites.

Our payment card systems are adequately segmented from the intranet by firewalls, access control lists, and other measures. We believe there is adequate segmentation that "isolates systems that store, process, or transmit cardholder data from those that do not" as quoted from PCI DSS 1.2. Our users of our VPN have no systematic way to access to any payment card system or data through any means.

However, our Information Security group is compelling us to their standardized firewall on our VPN that would be burdensome upon our users and would prevent some from using the VPN service at all.

In your opinion, is our VPN system out of scope? Is there a general trend across companies to secure the perimeters for PCI DSS compliance even though payment systems are "adequately segmented"? Is this scope creep at work?

:confused:

[jbhall56]

Sounds more like an internal political problem and not a PCI compliance issue. However, I'm assuming that your Security group is getting wound up over your organization's PCI compliance. I'm also assuming that you are a Level 2, 3 or 4 merchant as you do not have a QSA involved who would be the ultimate arbiter in such a discussion.

That said, based on the information you have provided, the solution you document would appear to meet the requirement of segmenting the network appropriately and keeping your executive VPN and their computers out of scope.

[MktgMind]

Thanks so much. Looking at the tiers, we're definitely a Level 1 merchant. Our team is no stranger to regulatory compliance, but we were just told our VPN system users are in-scope last week, and PCI is very new to our team.

Thanks for letting us know about the QSA as an arbiter. I didn't know that was an available resource.

Also, does PCI DSS have an exception/mitigation process? Kind of like how SOX 404 compliance efforts allowed exceptions/mitigation of gaps to the COBIT framework, as long as those mitigating controls were disclosed and documented?

[cmark]

Just to be clear...1) a Level 1 does NOT require the use of a QSA and 2) the QSA is not the final word nor the ultimate arbiter of any interpretation or scope. Their job is to provide a finding of compliant or not based upon the information provided. That being said, there are a number of instances where companies and QSAs disagree and the discussion must be taken elsewhere.

The QSA, if selected, must use the interpretation of the PCI SSC. In the case of merchants, the acquirer is the ultimate arbiter of the scope etc.

There are no exception processes but there are however compensating controls that can be employed.

We are seeing more and more Level 1 merchants forgo the use of QSAs and self assess.

[jbhall56]

Thanks for letting us know about the QSA as an arbiter. I didn't know that was an available resource.

To clarify my comment. While CMark is correct that the acquiring bank/processor is the ultimate arbiter, it has been our experience that the QSA provides the internal arbitration and gets everything lined up so that the acquirer/processor does not arbitrate so much as they either decide to accept or deny the acceptance of conditions.

Also, does PCI DSS have an exception/mitigation process? Kind of like how SOX 404 compliance efforts allowed exceptions/mitigation of gaps to the COBIT framework, as long as those mitigating controls were disclosed and documented?

We do a lot of work with organizations that need to comply with SOX as well as other requirements. Whenever possible, we always try to use existing compliance work rather than recreating the wheel. However, in some instances, the other compliance work is just too out of date to be relied upon and we have to reperform the testing. However, when we reperform testing, we try to make it usable for SOX and other compliance work so that it's still useful alter on.

And, while CMark indicates that a lot of Level 1 Merchants are doing their own assessments, we are finding that a lot of them either give up or botch them. Some internal assessments are so bad, that their acquirer or processor tell them that they need to get a QSA to assist them with the PCI assessment process. The problem is that internal people just don't have the knowledgebase to conduct the assessment. Hopefully, the SPSP will address this lack of knowledge with their training efforts.

[MktgMind]

Thanks for all the help everyone. I raised a few of the points mentioned in this thread with our security team's regulatory & compliance manager.

Like jbhall suspected, it is more of an internal maneuvering and not really a PCI compliance issue. I suspect PCI is a reason (good, bad, or indifferent) to remove exceptions to our company's security policies; based on the fact that we're doing self assessment and our team is stonewalled from challenging the scope.

So we're now tasked with finding a solution that meets PCI DSS as written while making it easy on our less tech savvy executive clients.

Again, thanks for all the help. I'm sure I'll have more questions about what PCI DSS requires as we find the right solution I will try to contribute to this board where I can.