PCI DSS Compliance: Success Factors

This is Why Scoping, Segmentation & Tokenization Are the Key Success Factors Towards PCI DSS Compliance

So, what are the reasons organizations fail PCI Audit?

In December 2013, credit and debit card data breaching that happened to an American discount retailer, Target, that affected 40 million shoppers who went to the store in the three weeks after Thanksgiving. This incident shows us how actual and real the threat that many organizations such as merchants are facing today. The needs to protect cardholder data And this is the primary objective of PCI DSS.

While being compliant to PCI DSS requirements is very important but many organizations still find it’s not easy to comply. This article covers some issues that cause PCI audit failures so we can take a lesson and do it better when we prepare to comply with the standard.

1. RIGHT SCOPE

Scoping of PCI DSS assessment is very important. Scoping defines the certification boundaries. Successful PCI DSS compliance heavily depends on the correct identification of the scope of assessment. The right scope will make you much easier to comply and at the same time reduce the cost of compliance. If your scope of PCI DSS assessment is too narrow you could potentially put cardholder data in danger, but if too broad it will make your effort harder and costlier and adds unnecessary cost to achieving PCI compliance. The PCI DSS categorizes system components as being either in-scope or out of the scope of assessment. Open PCI DSS Scoping Toolkit has a good method to clearly categorize each system component that will help us define the scope of PCI DSS assessment. The toolkit defines three categories of system components, so we can categorize each component based on this. Then we can define which system components are the most important to protect, and which are less or not too important to protect. Every system component within an organization can be categorized into one and only one of the following:

• Category 1 – System components that process, store or transmit cardholder data or are not isolated or restricted through controlled access from other Category 1 system components.
• Category 2 – System components that have controlled access to a Category 1 system component.
• Category 3 – System components that are isolated from all Category 1 system components.

After categorizing system components, we can define which components in-scope and which ones are out-scope of a PCI assessment, as shown by the following tables.

2. IMPLEMENT SEGMENTATION PROPERLY

Not implementing network segmentation is one of the biggest reason why an organization fails to comply with PCC DSS. We can minimize the scope using network segmentation. Segmentation means separating system components or devices that store, process or transmit cardholder data with the other components, keeping PCI-protected payment information away from less important data. We consolidate cardholder data into fewer locations and more controlled environment (i.e. CDE or Cardholder Data Environment). According to the PCI DSS, “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the cardholder data environment (CDE), such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.” So, it’s clear that segmentation can be very useful to reduce the scope of PCI DSS assessment and reduce the cost of the PCI DSS assessment. Without segmentation, for example, card-processing systems will be mixed with back office systems. This arrangement could cause the entire network in the scope for PCI DSS compliance. This will increase the amount of work to comply the standard which can increase the possibility to fail to comply the standard. We can implement segmentation by using several technologies, as follows:

• Tokenization Tokenization can be done to reduce the scope of assessment. Tokens are used to replace sensitive data such as primary account number (PAN) data or credit card numbers. Credit card tokenization randomly generate a value to replace credit card data. Because tokens are randomly assigned, it’s impossible to compromise or reverse-engineer a token. The only way to see which credit card values associated to which tokens is through a token vault that is usually managed by a third party. By using tokens instead of PAN data or credit card numbers, merchants never see customer credit card information. They see only tokens, which are useless information for them. PCI DSS states that, “Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply. Storing tokens instead of PANs is one alternative that can help to reduce the amount of cardholder data in the environment.” This means that tokenization can reduce the number of system components that should be assessed because the system components no longer stores or process cardholder data, only tokens. This will reduce the scope of assessment and finally reduce the cost for compliance. The tokenization systems components such as card vault and de-tokenization are part of the cardholder data environment (CDE) and therefore in scope for PCI requirements. In the situation which the card vault is handled by a vendor, it will be out of scope of the business that taking the payment cards. Organizations that use tokenization provided by third party, must ensure their tokenization vendor has been approved through the PCI SSC, and that they protect tokenization systems and processes with strong security controls.
• Implement strict access control According to PCI DSS Guidance for PCI DSS Scoping and Network Segmentation, in order for a system to be considered out of scope, controls must be implemented to give a reasonable assurance that the out-of-scope system cannot be used to compromise an in-scope system component, because the in-scope system could be used to gain access to the CDE or impact security of the CDE. Examples of controls that could be applied to prevent out-of-scope systems being used to compromise the in-scope systems, are as follows:
• Host-based firewall and/or intrusion detection and prevention system (IDS/IPS) on in-scope systems that block connection attempts from out-of-scope systems.
• Physical access controls that allow only designated users to access in-scope systems.
• Logical access controls that permit only designated users to login to in-scope systems.
• Multi-factor authentication on in-scope systems, such as two-factor authentication (2FA)
• Restricting administrative access privileges to designated users and systems/networks.
• Actively monitoring for suspicious network or system behavior that could indicate an out-of-scope system attempting to gain access to an in-scope system component or the CDE.
• Access rule via proper firewall and router setting We can use firewall and router rules to ensure that there is separation between network components or device such as public servers, corporate LAN, and CDE (Cardholder Data Environment). For example, we can set rule to make no traffic that originated from the corporate LAN is allowed into CDE. Remember that all controls to establish segmentation (such as firewall setting that limits connections to specific ports or services on specific systems) should be included in PCI DSS assessment to validate their effectiveness.

3. REMEMBER THIS GUIDELINE

The PCI compliance may be less expensive and much less frustrating if we use the above strategies and follow this guidance:

• Do it wisely, do what you need and only what you need. For example, access to CDE should be given based on business needs only.
• Consider business constraints.
• Consider ALL business processes. The strength of your security is equal to your weakest link. A company may implement tokenization, but at the same time, if its employees leave out the voice recording system or fax system unattended, your tokenization will be useless.

Carefully considering the strategies and guidelines in this article will enhance your chance to successfully comply PCI DSS.

Figure 1. System Component Categorization (source: Open PCI DSS Scoping Toolkit)Figure 2. Mapping System Components Categories and Scoping of Assessment (source: Open PCI DSS Scoping Toolkit)