Thinking About Scope and Scope Reduction Techniques

When dealing with PCI DSS compliance, one of the first and most essential steps is addressing scope. My colleague, Walt Conway, calls it Requirement 0: reduce the scope of your payment environment to reduce your compliance burden.

This is good advice; reducing your scope by eliminating data stores, simplifying your transaction process, or segregating your payment-related networking from other stuff does, in fact, reduce your scope and, if done correctly, will actually help you secure your really important assets from attack.

In the last few years, we’ve seen some interesting developments in some additional scope-reduction technologies and techniques that I’d like to discuss here as well, namely tokenization and point-to-point encryption.

Segmentation

Segmentation separates networks at a logical layer, dividing one portion of a network from another using firewall rules which restrict network traffic from one segment to another. It’s a bit like how most modern ships are built; one interior portion can take on water, and it doesn’t flood the whole thing and sink the ship.

Segmentation also means you can apply a different layer of security to your less critical stuff. It’s probably the easiest means of reducing your scope for compliance available to you, but it’s also fairly easy to make some major mistakes.

Most of our clients want or need to permit something into the protected segment, such as the workstations of their IT staff, or permit something out, such as the servers being able to connect to Windows Update to get software patches.

How far down does this rabbit hole go? If your protected zone systems rely on Windows Active Directory authentication and your domain controller is outside your protected segment, does that invalidate the segmentation? What about a reporting function that needs to access your protected database, but only for non-card data?

Ultimately, this question gets the standard QSA answer: it depends. Cold comfort to many, I’m sure, but we’ve found these cases very situation-specific and that a lot of factors make or break the viability of a particular segmentation effort. Tighten the screws too much and you need a separate domain controller and a separate user account and password for the card data network than the garden-variety email and file sharing network. Too little, and the weak or weaker security controls in a non-critical environment impact the security of your payment network.

In the end few organizations can afford to ignore segmentation when dealing with their compliance obligations or carefully thinking about how to do so in an effective manner.

Tokenization

Tokenization has emerged in the last few years as a means of not storing actual card numbers. Often, the merchant exchanges the card number for some other (usually numeric) value with the payment processor; the processor keeps the card number and has to worry about the hard PCI DSS crypto and key management requirements (since they usually do anyway), and the merchant doesn’t store card numbers any longer. The merchant can even use this token in lieu of the card number for things like batch settlement or recurring transactions.

Using tokens in this fashion can greatly help organizations with their PCI DSS compliance obligations. If you’re not storing cardholder data, then the requirements that pertain to protecting card data in storage go away. This means the tricky bits about key management in PCI DSS 3.5 and 3.6 get to be your payment processor’s problem and not yours. That’s a decent gain.

The systems that accept the payment and handle it or that connect to the network on which the payment handling occurs are still in scope for all of the other PCI DSS requirements, so there’s no kitchen pass on applying patches, good user account practices, reviewing log activity, or the like. Also, very importantly, the system that does the tokenizing (is that even a word?) is very much in scope.

So depending on your prior payment data flow and how your tokenization works, your scope may not change very much or at all. You’ll get out of some painful cryptographic controls inside of Requirement 3, but the PCI DSS is still very much applicable to your organization.

Point-to-Point Encryption (P2PE)

Ok, this is where things get woolly. The PCI FAQ has stated that encrypted card data, where the entity possessing the encrypted data does not have the means to decrypt it, may be out of scope for PCI DSS compliance.

The PCI SSC has revised the FAQ text a few times and their most recent iteration states that they’ll be releasing more guidance on this in the future. This is good news, as this FAQ item has provoked some very interesting questions and PCI DSS compliance offerings.

If you’re a merchant and you’re doing P2PE, such that your point of sale (POS) system doesn’t see unencrypted card data and you “[do] not have the means to decrypt” the card data, then much of your scope, and by consequence your PCI DSS obligations, could go away.

Unsurprisingly, several service providers have begun offering this kind of solution to merchants and payment application vendors alike, claiming that their offering will remove the need for these entities to validate compliance with PCI DSS or PA-DSS. While I think that solutions like these make excellent ways of meeting the PCI DSS requirements, I’m not certain they will help anyone avoid their PCI DSS compliance obligations. Let’s examine this more closely. The text of the FAQ states:

encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entity’s environment, from obtaining access to Keys [sic].

So the FAQ states that not only can the system owner not be able to decrypt the data, but also that an attacker who compromises the payment network cannot obtain, deduce, or influence the key values by some surreptitious means to decrypt the data.

That’s a tall order. Does that mean that software solutions for P2PE can’t work, since, by their nature, an attack against the operating system could influence the cryptographic mechanism? What if it’s a hardware device with some device driver that runs on the allegedly out-of-scope POS? What if the hardware encrypted magnetic stripe reader requires a firmware update? Good questions, that, and I’m not sure there are official answers for any of them.

The PCI SSC did release an initial roadmap for P2PE. It’s worth reading, but know that it doesn’t contain the definitive guidance for which you’re looking. That’s slated for later.

So this, like tokenization, makes for an excellent means of meeting the PCI DSS or the PA-DSS, but probably doesn’t obviate the need to comply with it altogether. It might shake out that way when we see more formal guidance. Or not. But in the interim, as an assessor, I’m hard-pressed to rule things out of scope for compliance with this many unanswered questions.

In Summary

When thinking about your PCI compliance obligations, scope is the first and foremost thing to consider. It is of such importance that we revisit scope again and again throughout an assessment.

Some of the techniques here could help you with managing your scope, but keep in mind that any solution you look at will have some very situation-specific qualities to it, and your results may vary from other organizations that employ similar solutions. Work with your assessor on this one; he or she is just as interested in managing scope well as you are.

Notes

  1. Jacob Ansari submitted this to 403labs