How to Go Beyond PCI Compliance to Secure Your Organization: Requirements 1-3

In the first post of this series, we discussed the Payment Card Industry Data Security Standard (PCI DSS), why it is important, and what the consequences are of being non-compliant. We also explained why being PCI compliant is not enough.

Visit our Business Guide to PCI-DSS Compliance Training for more information

In this post we cover the first three PCI requirements to see how we can do more than just check the compliance box. Before we dive in, let’s review how the payment process works.

The payment workflow

When you use your credit card to pay for something, this process is straightforward and invisible. You swipe a card or submit credit card data in an online form, and in just a few seconds the transaction is completed. Easy and convenient!

It's not quite that simple behind the scenes. Credit card processing is more complex and involves at least three different organizations. The following figure illustrates the basic concept behind this process.

1. The customer enters card data into the merchant’s payment gateway (POS terminal / online gateway)
2. The details are forwarded to the acquiring bank/processor (e.g. Stripe, Paypal)
3. The acquiring bank requests authorization from the credit card vendor (e.g., VISA, MasterCard), which forwards the customer’s credit card data to the issuing bank (e.g. JPMorgan Chase, Goldman Sachs)
4. The issuing bank verifies the card data and authorizes the transaction
5. The issuing bank routes the response back to the merchant
6. The merchant may store the transaction data for recurring payments, refund requests, or other reasons

During this process, the credit card data goes through different states. For example, when the customer swipes the card or enters the data into the merchant’s online store, the plain-text cardholder data is “in use”. While traveling between the organizations, the cardholder data is “in transit” (steps 1, 2, 3, 5). When the cardholder data is saved in the merchant’s database, the data is considered “at rest” (step 6).

In any of these states, the cardholder data is susceptible to a cyber attack. While the data is “in use” or “in transit,” an attacker may intercept the credit card data (network traffic sniffing) or steal the plain-text directly from the POS memory (POS RAM scraping). However, most attacks target “at rest” data because with a simple vulnerability, an attacker can gain access to millions of cardholder data records at one time.

PCI DSS tries to address these security issues by providing best practices that cover the entire payment processing workflow, including at the application-building level with the requirement of PCI developer training. PCI DSS has made a significant contribution in securing cardholder account data and other sensitive information.

But things are far from perfect. As we discussed in our first post, PCI DSS is not enough to secure your organization. The biggest problem with PCI DSS is that it is too vague, providing only a general overview of the cybersecurity best practices without many technical requirements.

For example, let’s take a look at the first PCI DSS requirement, which says, “Install and maintain a firewall configuration to protect cardholder data.” Many merchants can simply install a firewall and meet this requirement, but are they really protected? In most cases, the answer is no.

Let's dig in to the first three PCI requirement and discuss how to go beyond compliance to secure your organization. 

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

The best way to approach this requirement and go beyond PCI compliance is by understanding your network architecture and how different systems communicate. First, take a look at each device in your network and answer the following questions:

• What is the purpose of this device?
• Who should be able to access it?
• What are the services that run on this device?
• Should it be available outside of the internal network?

Start creating strict firewall rules based on the answers to these questions. Ideally, you should use an allowlist approach: allow only approved apps, software, emails, domains, ips, etc. and block everything else.

Next, add restrictive rules to deny administrators access to specific devices outside your firewall. This will help you prevent unauthorized access via both external and insider threats.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

If you check publicly disclosed vulnerabilities from bug bounty platforms, you will see a lot of reports related to this requirement. Either an unprotected administration panel is used, a database instance is using a root:password combination, or a web server with known vulnerabilities is used.

These kind of issues can have serious consequences. According to Verizon’s 2019 Data Breach Investigations Report, 81% of data breaches are caused by compromised, weak, and reused passwords.

To be compliant with this requirement, as soon as you install new software, make sure you follow the recommended guide for hardening. Applications come from the vendor with a default configuration that usually does not take into consideration security. Instead it is optimized for usability.

It is your responsibility to implement additional protection mechanisms. Install only what is required by your application and nothing else.

To go beyond this requirement, you should consider a defense in depth approach. First, you should think of your software deployment process and try to separate duties for development, testing, and operations. For example, set up your process in such a way that the developer who deploys the code doesn’t need to have root access to the production environment.

Further, you should isolate the servers based on function. For example, instead of using an all-purpose server that hosts multiple applications, why not move each application to a different server? This will make the management process more transparent and streamline the process of keeping dependencies up to date.

Also, if you have a testing environment for a product, that server can be part of a local network, decoupled from the Internet. This technique is called “air-gapping” -- a security measure used in military and industrial control systems.

Requirement 3: Protect stored cardholder data

The best way to comply with this requirement is to not store any cardholder data. Instead, you can use a payment gateway and store only the customers' ID and successful payment confirmations, or you can use an approach called tokenization.

Tokenization replaces sensitive information like cardholder data with a random string called a token. The token reveals no sensitive information about the original data and cannot be modified to reveal sensitive information. A token is just a meaningless sequence of digits and letters that has no value for an attacker.

As soon as your application receives sensitive data, it securely forwards the data to a tokenization server, which generates a random token. Next, the tokenization service stores both the token and the sensitive data in a secure database that is external to your server. Finally, the token is returned to your application and stored in a database. You don’t store any sensitive information in your database, but if your application needs the sensitive data, it can be easily accessed from the tokenization server.

This approach is easy and cost-effective to implement. It will also reduce your PCI scope, making the PCI compliance process easier.

If you do not use tokenization, there are other solutions such as point-to-point encryption (P2PE), end-to-end encryption (E2EE), or credit card vaulting. They all have their pros and cons, so the idea is to choose whatever best fits your organization. The important point is to choose some method that protects sensitive data.

Regardless of the solution you choose, keep in mind the following:

• Avoid storing cardholder data as much as possible
• If you have to store sensitive data, make sure data is encrypted with a secure cryptographic algorithm
• Never transmit cardholder data in plain-text
• Retain cardholder data only for as long as needed

The next post in this series covers additional PCI requirements and further explains the value of protecting your organization by going beyond merely checking the compliance box, including the importance of PCI developer training.