Lessons Learned from Implementing PCI DSS

 

By Kumar Setty, CISSP, HCISPP

Most experienced security professionals encounter or are required to assess PCI DSS (Payment Card Industry Data Security Standard) compliance based on 12-point criteria.

Any business that transmits, stores, handles or accepts credit card data — regardless of size or processing volume — must comply with PCI DSS. That includes hospitals, restaurants, retail outlets, and any other organization using e-commerce and accepting or handing credit and debit card information for payment.

The ultimate penalty for noncompliance: Payment card brands terminate the merchant relationship with the organization, cutting off what for many is now their consumers’ primary payment method. Other penalties include fines until the deficiencies are remediated.

Yet issues remain. I know because I’ve experienced them, and now wish to share what I’ve learned so others avoid them.

PCI DSS in its entirety
The most common problem I’ve witnessed is the lack of proper scope definition. The scoping step sets the stage and tone for the entire PCI compliance assessment. When scoping the cardholder data environment (CDE), it is important to start by assuming the entire IT environment falls within the scope until it can be verified that all the necessary controls are in place, providing proper segmentation of the CDE. By ensuring that proper segmentation is in place, you greatly reduce the risk of CDE systems being impacted by security weaknesses originating from out-of-scope systems.

PCI defines an in-scope system as one that “stores, processes, transmits and/or can affect the security of the cardholder data environment.” To reduce PCI scope, network segmentation requires careful planning, design, implementation, monitoring and documentation. One commonly overlooked system is the VoIP (voice over IP) system. If the organization relies on a call center using VoIP to collect credit card numbers, and if this VoIP data is transmitted over a local area network, this entire LAN may fall within the scope for PCI DSS compliance.

Additionally, if these VoIP calls are recorded and stored, then the storage server or storage area network may also fall within the scope, along with any backups. Since storing any cardholder data can significantly increase the scope footprint of the CDE, these types of scenarios can significantly affect the scope process of the assessment.

Impact of outsourcing
Another popular practice is outsourcing the entire payment process. When a merchant uses a validated third party to capture the payment information from its own website, the actual process of data capture bypasses their systems. In this way, the merchant does not need to store cardholder data in house; thus, this alleviates some of the requirements associated with PCI compliance. If the business can demonstrate clearly that no cardholder data resides in its environment, in most circumstances completing PCI SSC Self-Assessment Questionnaire A should suffice. This reduces the scope of the PCI compliance program to just 22 controls. A significant number of these controls are related to selecting and managing third parties, but nonetheless the burden of compliance is much lighter on the merchant.

Tokenization
Tokenization is also another process that can reduce the scope of a PCI CDE. Tokenization swaps highly confidential payment data for a “token” consisting of random digits that cannot be restored to their original payment data values. This token is created after transmittal to the payment processor. The token is then transmitted back to the merchant and used to identify the customer in the merchant CDE. If the customer chooses, this token can be used to process recurring transactions.

The advantage of tokenization is that the merchant is not storing or processing cardholder data in the clear, and the responsibility of securing that data lies with the payment processor. Since the token is created by the payment processor tailored to the merchant specifications, this token cannot be used by another merchant or business, thus even further protecting the cardholder’s data.

Threat modeling and asset management
Another often overlooked aspect to the scoping exercise is threat modeling. Threat assessment is not explicitly required in the PCI DSS framework, but it’s helpful in understanding elements of high risk or outlier risks. As a starting point, the merchant or business can list out all the PCI requirements in one column. In the next column, list the assets and systems responsible for supporting the PCI requirement. In a third column, as part of a group or individual exercise, list the threat element or abuse case (“What could go wrong?”). In the final step, calculate likelihoods, impacts and overall risk levels.

Asset management is the other area where I have noticed room for improvement. Missing or incomplete asset inventory is a common problem. In more mature organizations, the asset inventory may be maintained in a system of record, and it may be automatic or part of the primary responsibilities of a team. In less mature companies, the asset inventory might consist of an Excel spreadsheet that is manually maintained and at risk of being out of date or incomplete.

Regardless of the tracking method, the main objective should be an accurate and complete inventory of PCI assets. PCI DSS Requirement 2.4 requires that an organization “maintain an inventory of system components that are in scope for PCI DSS.” This inventory should include all hardware and software components within the CDE, a functional description for each asset, and IP addresses where applicable. Ensure that your asset inventories include all systems identified in both the network and dataflow diagrams.

The risks presented by a deficient asset management program are:

• Incorrect or inaccurate scoping of the CDE
• Incorrect or lack of identification of technology gaps or vulnerabilities

Ranking concerns
If I had to rank the issues I’ve seen or encountered, I’d put deficient scoping at the top. Scoping determines the entire tenor and magnitude of the assessment. In cases where an organization did not correctly scope the CDE, there were significant cost overruns and late identification of critical vulnerabilities.

Asset management is an important step in scoping the CDE. However, deficient asset management processes rarely create the same level of cost overruns and project failures as scoping deficiencies.

Ideally, all these areas are addressed, ensuring that everyone is able to regularly comply with these ubiquitous payment standards and continue to support the card transactions that we all increasingly depend upon.

Kumar Setty is a qualified security assessor (QSA) with Compliance View, where he performs PCI compliance services. He holds the following certifications: CISSP, HCISPP, PCIP, CISA, CCSK and ITIL, and he has more than 15 years of experience in security, privacy and fraud risk assessment.