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.