PCI zone and non PCI zone in same DataPower box

I’ve been having PCI Déjà vu lately.  It seems the same questions keep coming up over and over.  One strategy for compliance that is nearly ubiquitous is to segregate the PCI data from the rest of the network.  In practical terms, this usually means a dedicated subnet or network, firewalled from the rest of the intranet and with dedicated software and hardware components.  When people approach PCI compliance as simple configuration they eventually ask “why not put the non-PCI data in the PCI enclave?”  The theory is that if the PCI network is good enough for the PCI data then it is good enough for the less sensitive data and having just one set of components would cut costs.  Because I’m lazy and didn’t want to write yet another response to this, I thought I’d post the latest one here.

A colleague sent an email with the subject “PCI zone and non PCI zone in same DataPower box” today and asks the following question:

I would like to pick your brain regarding a question from customer.  They want to share the same DataPower box for PCI and non PCI data.

The premise of the subject line is wrong.  It is not possible to have the PCI and non-PCI zones in the same hardware or software component.  For purposes of PCI a component is either in scope or not in scope for the assessment.  If PCI data runs through the component in plaintext (or encrypted if the component has access to the keys) then the component is in scope.  So the DataPower box in this scenario would be in scope for the assessment because of the PCI data it handles.  What you actually have here is a question about running non-PCI data through the PCI zone.

What does “in scope” mean?  This is not a comprehensive list but the following apply:

  • All points of data ingress or egress must be accounted for and PCI controls applied.  (Shut down unused ports, change default passwords, authenticate users, etc.)
  • All legitimate users must be accounted for and role-based access control with least-privileged authorizations applied.
  • Adequate controls must exist to assure that PCI data does not leak to unintended destinations.
  • Sufficient auditing and monitoring must be in place to verify all of this.
  • Monitoring must be able to flag unusual or unauthorized data access.

Any system can be made PCI compliant despite routing non-PCI data through it.  The question is whether the cost of compliance exceeds the cost of segregating the data.  Those costs come in the form of implementing the necessary controls but also there are additional recurring costs because the scope of the assessment is expanded.  For example, if you have an egress route for non-PCI data you must show that sufficient controls exist to GUARANTEE that PCI data will NEVER flow through that path.  Two non-PCI egress routes?  Double that incremental cost.  Ten non-PCI egress routes?  Ten times that incremental cost.  These costs recur at every assessment.

Of all the systems where you might mix PCI and non-PCI data, a DP box is one of the best because it should be relatively easy to inventory data access paths and users, and it has good auditing capabilities built in.  However even with DataPower boxes there is a break-even point where the cost of monitoring, auditing, access controls and assessment on the non-PCI portion of the data exceeds the cost of a second box.  The key is to understand the costs of the controls and the recurring assessment costs against this expanded scope.  As a hardware/software vendor I am sometimes perceived as benefiting by selling two of everything to meet PCI compliance.  However what it really comes down to is that the cost of compliance and recurring assessments is reduced when PCI data is strictly segregated and that cost differential usually exceeds the cost of the extra hardware and software.  But in order to make that decision, you need to be able to do a good assessment of the alternatives and a cost/benefit analysis.

In the end, that’s what I recommend: to closely examine the cost of compliance on an undifferentiated network versus a segregated network and decide for yourself.  When you do buy that extra DataPower box or Broker license it won’t be because I recommended it or because it is a “best practice” but because that approach actually turns out to be less expensive than the alternative.

This entry was posted in General, WMQ Security and tagged , , , , , , . Bookmark the permalink.

4 Responses to PCI zone and non PCI zone in same DataPower box

  1. infohwyman says:

    T. Rob – You said it better in your reply to Maryellen, perhaps because you were answering a specific objection, you said the same thing in both sections but that first paragraph of your answer summed up what I have been taught for years as a Vendor Risk Manager trying to keep risk, not so much costs contained, and that was always to minimize any chance that the scope of PCI would be taken out of proportion by allowing non-PCI data to connect, thereby expanding the number of ingress and egress data points and thus the scope of PCI to the rest of the network by not having contained PCI zones more carefully.

    • T.Rob says:

      Thanks for the read and the comments. Nice that half my comments (so far) seem to understand what I was getting at. While PCI can be complicated, the basic ideas here should not be: 1) creating a PCI enclave/segregated network is intended to reduce risk by isolating the PCI data, and reduced risk means reduced cost of the audit; and 2) after going to the trouble to isolate the PCI data and processing, running non-PCI data through it brings that data into scope of the PCI audit.

      The comment that “Only a QSA can exclude technology…” completely misses the point. I’m not trying to exclude or descope anything. I’m trying to prevent the client from inadvertently bringing a boatload of data, and possibly up- and down-stream systems, into scope. The additional cost of scoping all of that will almost surely exceed the savings realized by using excess capacity in the PCI enclave.

      Side note – after reading Maryellen’s comment I pictured MC Hammer blocking the door to the data center, dancing around and singing “You can’t descope this.”

  2. T Rob- The article suggests that putting PCI data on datapower excludes WMQ from the assessment. The comment, “However what it really comes down to is that the cost of compliance and recurring assessments is reduced when PCI data is strictly segregated and that cost differential usually exceeds the cost of the extra hardware and software.” is disturbing. Nothing could be further from the truth. Only a QSA can exclude technology once it is diagramed and verified to be in the PCI scope. New guidelines on PCI have come out that speak directly to WMQ, ESB used by banks, data processors and merchants. The bottom line is that it is in scope for assessment. No software or hardward can descope a PCI assessment. Using the technologies afford greater degress of protection and make it easier to assess if they are used in the correct context. We have to stop telling system administrators pieces of the PCI puzzle and get to causes and conditions of non-compliance, primarily unathorized administrative access, using old versions and not securing the channels with TSL. I love you but we have to start making this very, very clear and not so muddy.

    • T.Rob says:

      Hi Maryellen – I do not disagree with your premise but you’ve been fighting this fight so long I think you are finding the opposing viewpoint where it doesn’t exist. Paraphrasing, the question was “if I have a segregated network for PCI data, can I run non-PCI data through it?” My response was that to do so would bring all that non-PCI data under scope of the audit. The business justification for building out the segregated PCI enclave in the first place has always been that the cost of isolating PCI data from all the rest of the applications and data is less than the cost of achieving PCI compliance on an undifferentiated network.

      My statement that “the cost of compliance and recurring assessments is reduced when PCI data is strictly segregated and that cost differential usually exceeds the cost of the extra hardware and software” should not be disturbing since it pretty much mimics the PCI council’s own guidance. They advise “Without adequate network segmentation (sometimes called a ‘flat network’) the entire network is in scope of the PCI DSS assessment.” They go on to say that “If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment.” (PCI-DSS Requirements and Security Assessment Procedures V2.0, October 2010) If reducing the scope of the assessment does not cost-justify the expense of the additional hardware and software required to segregate the PCI data from everything else then on what basis would anyone do it and why does the council recommend it?

      So if the purpose of creating the PCI enclave was to reduce the scope of the assessment, then doesn’t running non-PCI data through it as proposed in the question then expand the scope of the assessment and defeat the purpose of segmentation? Would not the correct response be to keep that data OUT of the PCI enclave, even if it means buying a new DataPower box through which to route it?

      I didn’t say or even suggest that putting PCI data on datapower excludes WMQ from the assessment. What I said was that if you already have DataPower in your segregated PCI enclave, that trying to save money by running non-PCI data through it is a bad idea. Just buy another box and host it in the non-PCI network. Other than that, I agree with your points. We need to address root causes and all those gaps you mentioned are real.

      Thanks, by the way for assembling the words “putting PCI data on datapower excludes WMQ from the assessment” into a contiguous string and posting them to my blog. It’s not something I would have claimed and set to writing but now that you have it’s sure to draw Google hits.

Leave a Reply