Merchants need to protect the cardholder data that they collect and encryption is one of the ways this is accomplished. Encryption by itself is not enough to place data out of scope for PCI DSS. This blog will cover what a cardholder data environment is, how encrypted data is part of that environment, and how encryption fits into the scope of PCI compliance.
Encryption
Encryption is a way to take everyday data, also called plaintext, and change it into code, rendering it unreadable by unauthorized personnel as a security standard. The data is encrypted using a cryptographic algorithm and can only be deciphered using the corresponding cryptographic key. Decryption is simply the inverse of encryption, following the same steps but reversing the order in which the keys are applied. One of the ways this is used in the business world is by protecting credit card or payment card data in storage or in transit. The idea being that if a hack occurs, the hackers will only get a coded version of the data and not the data itself.
Encryption and PCI Compliance
Before we get into where encryption falls in terms of being PCI compliant, here are a few basic things to start off with. First off we need to understand what exactly is meant by payment cardholder data. This term is referring to any data or information printed, processed, transmitted or stored in any form on a payment card. According to the PCI Data Security Standards, it is the responsibility of an organization accepting payment card to protect the cardholders information and prevent any fraudulent use of that information, whether the data is printed or stored locally, or transmitted over a public network to a remote server or service provider. These cyber security precautions help to protect businesses large and small against cyber attacks.
Here are the requirements enacted by the PCI Security Standards Council in regards to organizations storing cardholder data:
In general, no cardholder data should ever be stored unless its necessary to meet the needs of the business. Sensitive data on the magnetic stripe or chip must never be stored. If your organization stores PAN [Primary Account Number or card number], it is crucial to render it unreadable (see 3.4).
3.1 Limit cardholder data storage and retention time to that required for business, legal, and/or regulatory purposes, as documented in your data retention policy.
3.2 Do not store sensitive authentication data after authorization (even if it is encrypted).
3.3 Mask PAN when displayed; the first six and last four digits are the maximum number of digits you may display. Not applicable for authorized people with a legitimate business need to see the full PAN. Does not supersede stricter requirements in place for displays of cardholder data such as on a point-of-sale receipt.
3.4 Render PAN, at minimum, unreadable anywhere it is stored including on portable digital
media, backup media, in logs, and data received from or stored by wireless networks.
Technology solutions for this requirement may include strong one-way hash functions,
truncation, index tokens, securely stored pads, or strong cryptography.
3.5 Protect cryptographic keys used for encryption of cardholder data from disclosure and misuse.
3.6 Fully document and implement all appropriate key management processes and procedures for cryptographic keys used for encryption of cardholder data.
Cardholder Data Environment
The scope of something is the extent of the area or subject matter that something deals with or to which it is relevant. Being involved in credit card processing constitutes a few different components, which means PCI scope depends on what an organizations cardholder data environment (CDE) includes. Many businesses can be unaware of the components they are responsible for and which fall within scope. The easiest way to find out is by asking this question: does your business store, process or transmit cardholder data? If so, it must be PCI compliant.
Since the scope depends on the organizations CDE, how is that determined? During an assessment, it is duty of the organization to define its CDE and not a Qualified Security Assessor (QSA). The QSAs role is to take the CDE definition provided by the organization and confirm that the CDE definition is accurate based on the QSAs assessment work. There are a few things a company can do to prove their CDE is correct according to their definition.
First a company can start by tracking their cardholder data flow. Any equipment or application that transmits or stores cardholder data needs to be documented. Once the flow of data is realized, they can create a network diagram that shows all of the firewalls, routers, switches, access points, servers and other network devices and how they are architected. This diagram represents the CDE for that company, barring any data found during the next step.
Secondly a scan of their entire network is required to ensure that no cardholder data is stored outside of the CDE. Some companies have access to data loss prevention technology, which would be able to scan a network for any unencrypted data. Others may use a third party company that specializes in data loss prevention to scan the network. Either way, all cardholder data must be accounted for, and wherever cardholder data exists will comprise an organization’s CDE.
PCI DSS Scope and Encryption
Once again, anything within a CDE that transmits or stores cardholder data, regardless of encryption is within the PCI DSS scope and must be PCI compliant. According to the PCI SSC
the following are each in scope for PCI DSS:
- Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions
- Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes
- Encrypted cardholder data that is present on a system or media that also contains the decryption key
- Encrypted cardholder data that is present in the same environment as the decryption key
- Encrypted cardholder data that is accessible to an entity that also has access to the decryption key
Encrypted cardholder data (stored or transmitted) being out of scope is based on whether or not an entity has access to the plaintext cardholder data or the encryption process, or has the ability to decrypt the encrypted data. If a QSA deems that an entity does not have access to these three things, then the encrypted data is determined to be out of scope.
Stored Data
Under requirement 3.4 from earlier, we read that one of the conditions for storing the PAN is by using strong cryptographic keys. One of the ways that this is accomplished by organizations is by using a hardware security module (HSM), which is responsible for generating and managing the keys for cryptoprocessing. In addition to managing the keys, this device also provides an application programming interface (API) for code to access the keys. The module may be embedded in other hardware, connected to a server as part of a network, or used as a standalone device offline. HSMs would be in scope for a company even with the use of encryption because the company has access to the data through the API.
In the realm of data storage there is a condition that renders that cardholder data out of scope for an assessment. That condition is found in a third party, but only if certain requirements are met. The third party must only receive the encrypted data and not the keys that would be used to decrypt that data. The entity that is sending the data is responsible for the keys and the personnel that have access to those keys. The third party has the responsibility to only grant access to personnel appointed by that entity. In this situation the third party does not have the means to decrypt the data, and would therefore be considered out of scope for that third party. If tokenization is used by the merchant, the token would be out of scope, since the token isn’t considered to be cardholder data. A third party may also act as a means of routing encrypted cardholder data from one entity to another. The third party is not providing any security services or access controls and the security of the data would fall to the entity receiving the data. In that case, the third party would be out of scope for PCI compliance.
Transmitting Data
When cardholder data is transmitted, regardless of encryption, it needs to be secure in order to align with the terms of compliance. One of the ways a company can achieve this is by using transport layer security (TLS). This method provides communication security for encrypted data when transmitted over a network. If the company has access to the network encryption endpoint, then that endpoint is in scope. TLS is being used more and more as the encryption method of choice for point-to-point encryption (P2PE) solutions. Again, if the endpoints in the P2PE environment are under the control of the company being assessed, then the endpoint or endpoints are in scope.
What about users and devices on a communication link between endpoints? As long as the data is encrypted and those users and devices don’t possess the cryptographic keys, they are out of scope. While some personnel inside an organization have access to encryption keys, if a user or device does not have access to the encryption keys or the communication endpoints, they too are out of scope.
Applications
Applications, just like anything else that processes, stores or transmits cardholder data, are always in scope. These include point of sale systems like credit card terminals, e-commerce sites and management softwares. Due to the fall of complete applications and the rise of application package integration, it has become harder to determine the scope of those applications. In addition, many data processing applications fail to come with a data flow diagram, which can add to the confusion. Therefore it is important as a company to choose applications that make data flow clear and can make sure that data is encrypted and not in plaintext.
Software
To add onto the topic of applications, there is a type of software called middleware. Middleware reformats information streams so that one application package can communicate with another application package. There are application integration teams that have reportedly been unsure about the nature of the cardholder data when it comes to middleware. The uncertainty has to do with how the data appears, whether as encrypted data or plaintext. If you are unsure it is best to find out before installing such software.
Using a cloud-based software puts your servers out of scope because cardholder data is stored on a third party server. In terms of data encryption, companies are able to remotely access the encrypted data via the cloud.
Know Environment and Scope
In the end it is important to know what your cardholder data environment is and how to guard it. Encryption of cardholder data as a security control doesn’t guarantee that it is outside of that environment. If your organization has the ability to decrypt that data, whether stored or transmitted, then it is in scope. It is also important to remember that assessment should be all encompassing. Just because you determine something is out of scope doesn’t mean that it is. If necessary have a QSA assess what you have determined to be out of scope. The consequences for stolen data are far reaching and can have a huge impact on your company, not just service providers. Make sure to examine every component and you will reduce your risk.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.
References
https://blog.pcisecuritystandards.org/faq-how-does-encrypted-cardholder-data-impact-pci-dss-scope
https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf
https://searchsecurity.techtarget.com/definition/encryption
