PCI Compliance and the Cloud

Table of Contents

PCI Background

Introduction
What is PCI?
What are the PCI DSS requirements?
To whom does PCI apply?
What is considered cardholder data? Is the name, expiration date, and address important for PCI?
How does a company determine if an application or system is in-scope for PCI compliance?
It seems that the PCI DSS requirements may apply to me. Where do I start?
How does an auditor view an application that is not intended to take credit card information, but periodically is found to have credit card information stored within it?

Zendesk Q&A

How does PCI work with cloud service providers like Zendesk?
Is Zendesk PCI compliant?
I don’t want my end-users putting the full PAN in my Zendesk. How can Zendesk help me?
What additional Zendesk “technology” capabilities are available to me? How can I easily identify and truncate the PAN?
Tell me more about Automatic Redaction. How do I enable it and validate that it is working?
So why would I want to enable the PCI Compliant Ticket Field if the automatic redaction feature covers many more entry points and use cases?
Besides the PCI Compliant Ticket Field and Automatic Redaction, what other tools or techniques could I utilize to monitor and remove sensitive information in my Zendesk?

Redaction App
DLP and APIs
Going Forward
Glossary of Terms

PCI Background

Trust with customers is essential for any company. An important way for an organization to develop trust is to commit to protecting the data of its customers. With breaches on the rise and an ever-changing compliance landscape, it is vital to regularly review and scrutinize data protection practices.

The term “PCI” refers to the Payment Card Industry, consisting of credit card brands Visa, American Express, MasterCard, Discover, and JCB. In 2006, these brands jointly formed the PCI Security Standards Council (SSC), who then created a unified compliance standard called the PCI Data Security Standard (DSS). The intent of the PCI DSS is to provide a consistent framework for companies to secure payment card data, as well as methods by which to validate compliance with the standard.

The PCI DSS includes approximately 250 requirements spread across 6 high-level focus areas:

1. Build and maintain a secure network
2. Protect cardholder data
3. Maintain a vulnerability management program
4. Implement strong access control measures
5. Regularly monitor and test networks
6. Maintain an information security policy

PCI applies to both merchants and service providers that store, process, or transmit cardholder data (credit or debit cards branded with one of the five card brands listed above). “Cardholder data” specifically refers to the unique 15-19 digit Primary Account Number (PAN) found on a card; cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date, and/or service code. Simply put, if your company accepts or deals with credit cards, then you have some level of PCI responsibility. Service providers, as well as merchants that process a high number of credit card transactions (over 6 million annually), require annual external PCI assessments by a third-party QSA firm. Merchants with smaller transaction volumes are eligible to complete a Self-Assessment Questionnaire (SAQ). In both reporting methods, all applicable PCI requirements must be met in order to validate PCI compliance. For additional information, reference the PCI SSC website.

PCI generally only refers to the Primary Account Number (PAN). If other data elements (cardholder name, expiration date, and/or service code) are present without any PAN, then PCI DSS would not apply to those elements. However, if these other data elements are stored, processed, or transmitted with the PAN, or are otherwise present in the Cardholder Data Environment (CDE), they must be protected in accordance with applicable PCI DSS requirements (such as firewalls, patches, anti-virus, access controls, policies and procedures, etc.). Only the PAN itself, however, must be encrypted or rendered unreadable (PCI FAQ 1222).

Tip: Any time the PAN is stored, PCI requires that the number be rendered unreadable either through encryption, truncation, tokenization, or one-way hashing. Whether the card is encrypted or tokenized, the full PCI requirements still apply to that system housing the number, as the PAN could still be potentially reversed via compromise of the encryption keys or token lookup table, respectively. However, if the number is truncated (not masked) such that the system is storing a maximum of the first 6 digits and last 4 digits of the PAN, then the truncated number is no longer considered to be PAN (PCI FAQ 1091) and the full PCI requirements would not apply to that particular system.

The simple test is this: does the system store, transmit, or process cardholder data? If it does, then it is in-scope for PCI. Each company is responsible for identifying their systems where the PCI DSS requirements may apply. The important thing to consider is that PCI not only requires all baseline systems that store, transmit, or process cardholder data to be in-scope for PCI, but also all other systems directly connected to those baseline systems*. Scoping can be explored using the following steps:

1. First, recognize and document all known data flows and systems that are expected to transmit, process, and/or store cardholder data. These systems make up your baseline CDE.
2. Second, document all directly connected system components to the baseline environment. These systems are also considered part of your CDE.
3. Third, explore systems outside the CDE that you have reason to believe may be transmitting, processing, and/or storing credit card data. Document any that you find (both expected and unexpected) and see if you can trace them back to the CDE. Examples may include email systems, help desks, HR repositories, financial reporting systems, company spreadsheets, etc.

Tip: For systems where there is a dedicated credit card field, the scoping question is an easy one. However, for applications that do not have a dedicated field, but you suspect the application may be seeing credit card numbers keyed in, then it is best to validate exactly what sort of data is being stored or transmitted to determine if PCI compliance is required.

To enhance security and make PCI compliance more manageable, the next step is to determine if there are ways you can reduce your overall PCI scope. Review your CDE and scrutinize any interface that transmits, processes, or stores credit card data. Consider data protection best practices that suggest organizations should only acquire and consume sensitive data that is absolutely needed in order to meet critical business processes. Do you really need to store cardholder data? If there is no compelling reason, then don’t store it or find a way to minimize what is stored. Ask yourself the following:

• Do our business processes require the use of the card? How are we using the PAN?
• Are we storing the full PAN as a convenient reference number, or is used to support another business process (e.g. auto-billing or chargebacks)? If we are using the full PAN as a reference number, can we limit the use and storage by truncating to the first 6 and last 4 digits?
• Do we have control over whether a card number enters a particular system? For example, is the system associated with a web form, email, helpdesk, or some other externally-facing, public interface? If so, can we develop ways to identify and remove or redact the data as it enters the system?
• Are there ancillary systems that have interfaces into the baseline CDE that we don’t really need? Can we segment those systems through firewall rules or even remove the interfaces completely?
• Are our critical business processes architected soundly? Can we simplify the processes and remove systems from scope if we alter our processes?
• Are we storing the card for convenience? Is the storage use case clearly agreed to and understood by internal stakeholders, or is it being stored in preparation for some future need that may or may not present itself?
• Is the need to have access to the full PAN an uncommon edge case vs a common practice? Has the architecture over-accompanied these edge cases in its design?

Take the steps necessary to reduce the scope of your CDE down to what is absolutely needed either through network/system segmentation or removal of cardholder data. Question everything. The benefits include a reduction in the number of systems where PCI requirements apply, a less expensive audit process, and a smaller attack surface. The PCI DSS is weighty, and it can be challenging to maintain a compliant environment. Depending on your experience, resources, and available time, you may want to engage a PCI expert to guide you through the segmentation and scoping effort.

In this situation, is the application now considered in-scope for all the PCI DSS requirements?

Circumstances may arise where a customer or agent input credit card data into a ticket or application form field that is not designed to capture or store sensitive data. In these cases, you can choose to either include the system in the scope of your CDE and secure the data and system according to PCI requirements, or you can implement measures to prevent the system from being used to capture and store credit card data, and therefore effectively remove the application from PCI scope. These include:

• Policy – A policy should be written and distributed internally specifying that credit card data should not be input into the application or stored in the system.
• Awareness Training – Training on the policy should be in place to ensure that agents are aware of what is acceptable related to sensitive data entry and storage.
• Tools – Controls should be in place to prevent the capture of credit card data and/or to securely delete credit card data from the system before the data can be further stored, processed, or transmitted. This may include redacting or removing data.
• Monitoring – Periodically monitor the system to ensure that credit card data is not input or stored over time and perform risk assessments as necessary to validate your strategy for removing or preventing data input.
• Customer Communication – Find ways to educate customers on protecting their own sensitive information. Consider altering your email templates, chat applications, voicemail message, etc. to remind end users not to enter or offer sensitive information such as credit card numbers into forms.
• Auditor Communication – Share this whitepaper with your auditors. Discuss and work with them to optimize your business processes to limit risk.

You should communicate with agents and/or end-users on the risks of inputting and storing credit card data within systems. By proactively encouraging the use of secure payment methods only, you can reduce the amount of credit card data received via unsolicited or insecure channels (PCI FAQ 1157).

*Any network component, server, or application that is included in or connected to the Cardholder Data Environment.

Zendesk Q&A

So now that we better understand PCI and its requirements, let’s cover ways Zendesk can fit into a compliant PCI environment.

The term “service providers” refers to those entities that perform a service related to the transmission, storage, or processing of credit cards on behalf of their customers. For example, a payment gateway service would be considered a PCI “service provider” and would be expected to be PCI compliant on behalf of its customers. However, not all cloud providers play a role in the credit card processing lifecycle. While customers have the ability to use their Zendesk instance in various ways to meet their business needs, Zendesk is not intended to be used as a billing system or to transmit and/or store credit card data.

As a merchant, Zendesk is PCI compliant. As a service provider, Zendesk provides a feature allowing businesses to put credit card numbers into a custom ticket field (PCI Compliant Ticket Field) in the Zendesk agent interface. Credit card numbers entered into the PCI Compliant Ticket Field are redacted to the last 4 digits prior to the data being submitted to the Zendesk platform. This field and related controls are PCI compliant and an Attestation of Compliance (AoC) is available upon request.

There will be situations, regardless of what measures you may put in place, where a customer or agent will input a full PAN into locations outside of the dedicated PCI Compliant Ticket Field. As mentioned earlier, there are a number of things that you can do to help manage those situations including establishing clear policies, training your teams on data handling, leveraging technology capabilities, and performing sensitive data monitoring. To support your compliance efforts, we provide an additional product feature that allows you to automatically redact cardholder data from your Zendesk—through whatever means it may enter Zendesk.

To help our customers meet their PCI obligations, we are excited to introduce an innovative feature called “Automatic Redaction.” This feature applies the Luhn check algorithm as the PAN enters your Zendesk instance. When the tool identifies a credit card number match, it truncates the card number to the first 6 and last 4 characters, and tags the data indicating that the automated change has been made. The original credit card is not simply masked in the UI, but is completely redacted from logs and database entries, and is only stored in memory long enough to perform a Luhn check. The only storage exceptions are MIME encoded emails and custom ticket fields in suspended tickets, but we anticipate soon releasing functionality to remove these two exceptions.

Automatic Redaction allows you to mitigate situations where your customers may send you the full PAN. In addition, this feature allows you to easily search for the truncated PAN number within your Zendesk, which is especially helpful if your business processes require you to retain and reference the first 6 or last 4 numbers of the PAN.

In addition to reducing your overall security risk, you reduce your audit risk. Now, you have a tool to show your auditors that you have an effective process to keep the full PAN out of your Zendesk, and therefore keep your Zendesk out of your CDE. Pretty cool. Note the “automatic redaction” feature only redacts new data starting from the moment it has been turned on and it only covers Zendesk’s ticketing product, meaning not Help Center, Zendesk Chat nor other Zendesk products.

To enable Zendesk’s Automatic Redaction feature:

1. Click the Admin icon, then select Security > Global.
2. Select the Enabled checkbox in the Automatic Redaction section.

To learn more about redacting credit card numbers with our Automatic Redaction feature, read our support documentation here.

You can track the tickets with redacted credit card numbers in a view in Zendesk.

To list the tickets with redacted credit card numbers:

• Follow the instructions in this article in order to create a new view.
• Add the conditions “Ticket: Tags”, “Contains at least one of the following”, “system_credit_card_redaction”.
• Add a second condition, “Ticket: Status”, “Less than”, “Closed”.
• If you wish to see the tickets that were redacted and closed, you will have to create a second view. To do so, please follow the same steps but change the second condition to “Ticket: Status”, “Is”, “Closed”.

The key difference between the two features is when the redaction process takes place, and ultimately what PCI compliance obligations Zendesk has. With the PCI Compliant Ticket Field, the redaction function takes place prior to the credit card number entering the Zendesk platform. This feature has been audited and certified as PCI compliant, and is designed to handle credit card numbers. On the other hand, automatic redaction identifies and redacts credit card after the information enters our systems. Automatic redaction is not designed to enable you to accept credit card information. It is not a PCI compliant feature. Rather it is there to aid you in managing your PCI responsibilities and ensuring that you have the means to redact credit card information wherever it comes into your Zendesk.

In addition, in order to receive the benefits of our Attestation of Compliance (AoC), you will need to enable the credit card custom field. This field can be enabled such that only agents will see the field and your customers would not be able to utilize this field. Enabling this field obligates us to put your instance into a PCI compliant environment within 5 days from activation. Without activating this field, your instance may not benefit from the AoC or a PCI compliant environment.

While these two features provide you options for handling credit card data, some customers may have use cases where they need to identify and remove other sensitive information from the body of their Zendesk ticket comments. Zendesk is always developed with flexibility and simplicity in mind, and we encourage you to utilize our Redaction App, Data Loss Prevention (DLP) tools, and our APIs to meet your various needs, described further below.

Zendesk maintains an App Marketplace in order to host internally developed and community apps to enhance the Zendesk experience. Zendesk created the Ticket Redaction App which allows users to quickly redact attachments and/or partial comments from tickets. The app can be used while viewing a ticket, and it can be easily installed in your Zendesk instance. You can install the Ticket Redaction App directly from Zendesk’s App Marketplace.

To use Data Loss Prevention (DLP) and API tools, you will first want to export your Zendesk ticket data to a secure location for further analysis. You can do that in a couple ways:

1. Export the ticket data via CSV or XML
2. Export the ticket data via the Zendesk APIs by either utilizing the Incremental API to pull a list of tickets modified since a certain date or Utilizing our Listing Comments API to pull ticket comments from tickets identified in step a

Once you have the ticket data gathered, you can use an existing DLP tool (there are a number of paid and open source tools available) to help identify and match specific patterns of concern, including sensitive data elements like PAN. Then, you can utilize our Redaction API to remove the sensitive information from ticket comments.

At Zendesk we pride ourselves in listening to our customers’ requests and suggestions. The innovative features discussed in this document evolved from direct discussions with you, our customers! While we are hopeful that our PCI scoping advice and supporting Zendesk capabilities will help you lessen your PCI obligations, we are also aware that your needs will continue to evolve. We too will evolve, and will continue to look at additional security and compliance capabilities and new product features to build into the Platform.

Acquirer – Also referred to as “merchant bank,” “acquiring bank,” or “acquiring financial institution.” Entity that initiates and maintains relationships with merchants for the acceptance of payment cards. The acquirer is typically responsible for monitoring PCI compliance with their merchants’ account.

AoC – Acronym for Attestation of Compliance. This is the audit report that shows that Zendesk is PCI compliant for customers enabling the PCI Compliant Ticket Field.

Cardholder data – At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.

CDE – Cardholder Data Environment.The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.

DLP – Data Loss Prevention. Data loss prevention software is designed to detect potential data breach or data loss events.

Encryption – Process of converting information into an unintelligible form except to holders of a specific cryptographic key. Use of encryption protects information between the encryption process and the decryption process (the inverse of encryption) against unauthorized disclosure.

Luhn check – Also known as the “Mod 10” algorithm, it is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers. Most credit cards use the algorithm as a simple method of distinguishing valid numbers from mistyped or otherwise incorrect numbers.

Masking – A method of concealing a segment of data when displayed or printed. Masking is used when there is no business requirement to view the entire PAN. Masking relates to protection of PAN when displayed or printed.

PCI Compliant Ticket Field – This field is designed to accept credit card numbers from agents, where it will automatically redact the credit card number to the last 4 digits prior to the data being submitted to the Zendesk platform. This field is required to be enabled to benefit from Zendesk’s AoC.

PCI-SSC – Acronym for Payment Card Industry Security Standards Council. This council was established in 2006 by the five credit card brands (Visa, MasterCard, American Express, Discover, JCB).

PCI-DSS – The Payment Card Industry Data Security Standard. The PCI SSC created a unified standard by which all merchants and service providers would be subject.

PAN – Primary Account Number. Also referred to as “account number.” Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder.

Service provider – Business entity (not a payment brand) that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities.

QSA – Qualified Security Assessor. The PCI SSC has certified firms to perform PCI assessments and to assist with PCI validation; the designation is a QSA firm, or similarly an individual at a QSA firm can be certified as an individual QSA.

Redact – The process of removing sensitive information, such as PAN, where it is not needed.

SAQ – Self Assessment Questionnaire. An entity validating PCI compliance will either undergo an external assessment by a QSA, or complete an SAQ and submit it to the card brands or their merchant bank.

Tokenize – The process of breaking a stream of meaningful text, such as credit card number, into data elements called tokens that represent the actual data, but alone are meaningless. Tokenization is a method to remove credit card data from systems or databases, thereby reducing the scope of the CDE.

Truncation – Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates to protection of PAN when stored in files, databases, etc.