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

Originally posted here: https://blog.hackedu.com/how-to-go-beyond-pci-compliance-to-secure-your-organization-part-2-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. In addition, we mentioned why being PCI compliant is not enough.

In this post we will go through the first three PCI requirements to see how we can do more than just check the box. Before diving into the first three PCI requirements, let’s find out how the payment process works.

Understanding the payment workflow

For the end user this process seems straightforward. 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!

Behind the scenes, the credit card processing is more complex and spread across 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 considered to be “in transit” (steps 1, 2, 3, 5). Lastly, when the cardholder data is saved in the merchant’s database, we say that the data is “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 be able to 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.

PCI DSS tries to address these security issues by providing best practices that cover the entire payment processing workflow and more. This standard has had a significant contribution in securing cardholder account data and other sensitive information.

But things are far from perfect. As we discussed in the first post in this series, 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.

Now let’s discuss each PCI requirement and how to go beyond compliance to secure your organization. Let’s start with the first one.

How to go beyond PCI compliance

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 try to 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 a whitelist 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 can 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 root:password combination, or a web server is used with known vulnerabilities. These kind of issues can have serious consequences. According to Verizon’s 2019 Data Breach Investigations Report, 81% of data breaches are still caused by compromised, weak, and reused passwords.

To be compliant with this requirement, as soon as you install a new software, make sure you follow the recommended guide for hardening. Applications come from the vendor with a default configuration that in most cases does not take into consideration security, but instead is optimized for usability. Therefore, it is your responsibility to implement additional protection mechanisms. Install only what is required by your application and nothing else.

In order 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 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 their 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 keeping the dependencies up to date easier.

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” and it is 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 is the process of replacing sensitive information such as 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 and it will also reduce your PCI scope, making the PCI compliance process easier.

However, if you do not plan to 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 fits your organization. Regardless of the solution you may 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 will go into additional PCI requirements and explain protect your organization more than just doing the minimum.

Originally posted at https://blog.hackedu.com/how-to-go-beyond-pci-compliance-to-secure-your-organization-part-2-requirements-1-3 .