For those of us involved in the PCI DSS compliance process -- particularly those on the merchant side of things -- encryption can be confusing. Encryption serves two roles as both a mandatory and a discretionary control; for some areas, the PCI DSS is explicit that merchants must use encryption (PAN data at rest, cardholder data on public networks, remote access, etc.), but there are also situations where merchants can choose to encrypt...
for their own benefit. Because of this dual role -- and because it's not a concept that everyone is inherently familiar with -- encryption has historically been a source of confusion and can seem daunting to learn.
The PCI Security Standards Council has taken one step to clear the waters in this area in its recent document, Initial Roadmap: Point-to-Point Encryption Technology and PCI DSS Compliance (.pdf). The goal of this document is fairly straightforward: Provide clarity to merchants about certain types of encryption deployments, specifically PCI encryption requirements for point-to-point encryption (P2P encryption) products. For those in the merchant community who might be unfamiliar with what P2P encryption is or why they'd choose to use it, let's take a look at some of the key takeaways from the document to put in context what it is and why the council is releasing it now.
What is P2P encryption and why should I care?
From the outset, it's important to understand that this document is not intended to address every question a merchant might have about encryption. For example, a lot of people have questions about the encryption of data at rest, or stored cardholder data. This document is specific that it should not be used as guidance in that capacity. Also, this is not an implementation document; it does not provide validation specifics for QSAs, labs or other interested parties. The council does forward reference an upcoming publication -- "Validation Requirements for Point-to-Point Encryption" -- intended for publication in 2011, but for now it's using this document to provide specific guidance to merchants, not implementation or validation details. In addition, the document stays focused on the subject area, P2P encryption, or, encryption of data in transit between two different points on the network.
So why create a document entirely about P2P encryption?
To understand that, it's important to understand encryption of communication as it intersects PCI scope. Specifically, we know that any device storing, processing or transmitting cardholder data is in scope for PCI DSS compliance; we also know that systems not segregated from those devices are also in scope. But what constitutes segregation? Can encryption be used as segregation to "scope out" areas that would otherwise be in scope for compliance? This has been a murky question historically, because the council (on purpose) didn't say directly one way or the other.
Last year, the council started to resolve these issues by clarifying in its FAQ that encrypted data is out of scope (.pdf) when merchants can validate they have no ability to decrypt that data. This nugget of clarification provided a starting point for limiting scope. For example, after this guidance, merchants had a much better idea of how to scope situations such as handing encrypted backup tapes to offsite vendors. But, as useful as that clarification is, it does leave some questions unanswered.
For example, what if merchants buy a product from a vendor that encrypts at the POS and sends encrypted data all the way to the back end? Is that sufficient to "scope out" the intermediate network? If so, how much of the PCI DSS is scoped out; are there still parts of the standard that a portion of the network must comply with? And what does It mean to "validate that we have no ability to decrypt?"
Product vendors used the "reduce the scope of compliance" sales pitch to actively market products to merchants; since merchants have responded to this message, guidance to merchants from the council at this point is critical. And, of course, like most things, the answer from the council is based on specific sets of circumstances and is not "one size fits all." This document tells us that such scope reduction is possible, so long as it is in line with the council's previous guidance, but that merchants need to approach carefully.
What should I look at? What can I scope out?
It should be said that one huge win from this guidance is that now merchants know that the council intends to validate compliance of encryption products within the POS/POI space. That's good news. This means that vendors offering P2P encryption products will need to meet minimum security requirements, and that there will be a defined evaluation benchmark for those requirements; validation documentation will outline requirements for QSAs that, in combination with future training, will allow them to accurately validate deployments of P2P encryption products.
But the real meat of this document is focused on the "right here, right now" aspects of P2P encryption. In my opinion, the biggest value is in the advice to merchants about deployment "gotchas," aspects of P2P encryption deployment that merchants should consider now so their investments don't end up going sideways. For example:
- Key management effects -- Merchants need to make sure keys are managed appropriately according to the requirements of the PCI DSS standard . Future guidance will detail specific enhanced key management procedures for P2P encryption.
- Discovery -- Data discovery is a requirement as part of the limitation of scope. This means merchants are expected to actually look for cardholder data that may bypass the P2P encryption product, so they should have a plan for doing so from day one . Specifically, they should look to run a tool (for example, the open source ccsrch, or the PAN discovery features of a DLP product, if they have one) to automatically scan the environment for PAN, track or authenticate data. Enterprises should also ensure the discovery scope includes systems on both sides of the encrypted tunnel and that the discovery is thorough, looking across the entirety of the systems sampled.
- Data exports -- Situations where the data may be exported in plaintext format (legacy constraints, non-card gift programs, physical impressions from embossed cards, i.e., the "knucklebuster", etc.) may all serve to subvert a P2P encryption system and need to be addressed by the merchant prior to deployment.
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.