After conducting hundreds of Payment Card Industry (PCI) Report on Compliance assessments and providing PCI consulting for many organizations, our team at LBMC has identified several common issues and shortcomings that can cause significant challenges during a PCI assessment, resulting in costly remediation efforts and/or a failed PCI compliance assessment. This post describes the most common reasons that organizations fail to comply with PCI Data Security Standards (DSS) requirements. LBMC hopes that by identifying these common pitfalls and providing recommendations to avoid them, organizations can be better prepared to demonstrate compliance with the PCI DSS requirements, and that the outcome of a PCI assessment can be as expected for the organization.

Mistake #1: Not defining proper scope - know your scope

One of the most critical aspects of any PCI compliance effort is truly understanding your cardholder data environment(s) and what is in-scope and what is out-of-scope from a PCI perspective.

When scoping an environment for PCI DSS, it is important to always start with the assumption that everything in the IT environment is in scope until it can be verified that all necessary controls are in place and are providing effective segmentation of the cardholder data environment (CDE). Effective segmentation can greatly reduce the risk of CDE systems being impacted by security weaknesses or compromises originating from out-of-scope systems.

Improper scoping assumptions (labeling something as out of scope without proper verification) not only put a business at risk, but they lead to unpleasant surprises at PCI assessment time! To truly reduce PCI scope, network segmentation strategies require careful planning, design, implementation, monitoring, AND documentation. Many compromises of cardholder data environments have occurred via systems and networks incorrectly determined to be out of scope, where the breached entity placed false reliance on their segmentation approach only to find out after a breach that those controls were not effectively preventing connections to the credit card systems and networks. It is critical that entities focus on the security of their entire IT environment rather than solely on what is required by PCI DSS in order to minimize the risks to their networks and data.

PCI defines in-scope systems as any system that “stores, processes, transmits, and/or can affect the security of the cardholder data environment.” Most often, the phrase “can affect the security of” causes the most issues with the understanding of PCI scope. Below are some systems that are often considered “connected to” or “management” systems because they have a communication path to one or more system components in the CDE and can affect the security of the cardholder data environment, and therefore should be included as in-scope systems:

  • Authentication Servers
  • NTP servers
  • Patch servers
  • Log servers
  • Monitoring servers
  • AV management servers
  • RDP servers / Jumpboxes / Bastion hosts, other virtual systems
  • Administrative workstations
  • Wireless connectivity (wireless LANs, GPRS, Bluetooth, and cellular technologies)

Some of the most commonly overlooked systems that are often in-scope are Voice-Over-IP systems. In cases where VOIP systems are used to collect credit card data via phone (such as in a call center), the VOIP data is being transmitted via the local computer network, potentially bringing that particular network into scope. Other systems residing on this same segment of the network, including phones, would also fall into scope if not properly designed and segmented. Additionally, clients regularly store call recordings for customer service purposes and fail to take that into account when considering the storage of cardholder data. If calls containing credit card data are being recorded and stored, the systems storing the recordings would not only be in-scope, but any backups of the call recordings would also be in scope. Since storing cardholder data adds many more control requirements into a PCI compliance program, this oversight can have a significant impact on PCI scoping.

The PCI Security Standards Council (PCI SSC) has developed a “Guidance for PCI DSS Scoping and Segmentation” guide that can be utilized by any organization to help them identify the systems that, at a minimum, should be included in scope for PCI DSS. Additionally, the document provides guidance on how segmentation can be properly and effectively used to help reduce the number of systems that require PCI DSS controls.

During a PCI scoping exercise, LBMC QSA assessors will validate scope assumptions and segmentation controls that the organization has defined and determine which PCI controls are applicable to the environment. This is typically done via a thorough review of PCI network and cardholder data flow diagrams, asset inventories, and firewall rulesets. This process, which is executed well before any PCI assessment fieldwork begins, helps eliminate any confusion or surprises during the PCI assessment.  

One key point to remember regarding scoping is that an entity is responsible for ensuring that its scope is kept accurate on an ongoing basis. Organizations should always consider the impact on PCI scoping when planning network infrastructure or hardware changes, as well as other types of IT environment changes and upgrades.

Mistake #2: Not identifying business processes

One misconception about PCI compliance is that it is solely technical in nature. While there are many technical requirements, the business processes where credit card data is collected are just as important to document and be aware of in any environment. A second common mistake that organizations make is not considering all “payment channels” within the organization where credit card data is collected and stored.

Understanding and documenting all authorized business processes in place to accept credit cards is critical. Identifying and documenting each business process in place and the methods used to collect credit card data, as well as the underlying system components involved in the collection, processing, and transmission of the credit card data can provide a clear understanding of how credit card data traverses the environment.

For this process to be most effective, LBMC strongly recommends that key business unit leaders be involved in confirming that all credit card processes have been identified and are considered. In many cases, IT representatives are surprised to learn that a business unit has an additional payment channel that is not supported by the corporate IT department, but that must be secured.

How do you go about ensuring that your PCI DSS documentation meets the current standards?

1. Start small to build documenting into the culture.

Between all the policies, standards, and procedures, PCI documentation can seem like an overwhelming task. The best thing you can do is to start with what you know today and develop processes and systems your team can use to work through the documentation process.

2. Record what you know.

One of the most effective ways to initiate the documentation process is to designate a “documentation week”. During the week (or month if necessary), encourage your team to document every task you perform. Documenting while you’re doing it will make sure none of your current operations slip through the cracks.

3. Be disciplined.

Let’s be honest—PCI documentation can be mind-numbing. The best way to ensure compliance is to be disciplined and assume the proper perspective. Think of documentation as a necessary component of finishing any task, and then move on to other things.

4. Don’t worry about formatting.

When you’re first starting out, don’t get caught up on formatting your plan. That will only prolong the process. Instead, focus on getting all of your policies written out, and worry about formatting later.

5. Designate where and how you’re going to capture documentation.

It doesn’t help to have documents scattered all over the network or in team members’ personal folders. Instead, create a central repository, and put documents there as they’re created.

6. Assign an internal resource to formalize documentation.

Assigning a team member to the responsibility of formalizing documentation not only ensures everything is formalized consistently, but it also ensures the project gets completed.

7. Don’t be afraid to ask for help.

PCI documentation can be a long, arduous process. If you’re overwhelmed, don’t feel like you have to go at it alone. Consider finding a tech writer who can help you ensure your documentation is formalized and sufficiently addresses all compliance requirements.

Mistake #3: Missing or lacking asset inventory

In some organizations, an asset inventory may be generated from an asset management system, while in others, tracking assets may be a manual process. Regardless of the method of asset tracking, another common challenge for organizations is accurately and completely tracking and accounting for all PCI assets in an environment. 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 each in-scope environment and a description of function/use for each, and IP addresses where necessary. Ensure that your asset inventories include all systems identified in both your network and dataflow diagrams.

Mistake #4: Misunderstanding of SAQ eligibility criteria

This common issue is most often experienced when organizations do not fully understand how certain technologies or architectures are viewed and categorized by PCI. The most common areas where organizations misunderstand the Council’s SAQ eligibility guidance are:

  • Customer Service Representative (CSR) systems accessing a Citrix-like environment (which would potentially qualify for an SAQ C-VT). Organizations may fail to include the systems (i.e., the CSR workstations) that are inputting the CHD in their PCI scope.  
  • E-commerce solutions (assuming SAQ A vs. SAQ A-EP).  
  • As mentioned above, improper segmentation can affect which SAQ is applicable, as can storage of call recordings via VoIP.

In the SAQ documents, the Council has developed eligibility criteria for the various SAQs. It is critical for organizations to be aware of these requirements while architecting their environments and ensuring proper controls are in place to meet compliance.

Mistake #5: Falling behind on recurring tasks

In a previous blog post, we covered various recurring tasks present within the PCI requirements. Instead of regurgitating that article (read it at your leisure), this entry focuses on the following related mistakes: how misaligning scope can affect those recurring requirements and, secondly, even with proper scope, these tasks can be overlooked or forgotten. For time-based requirements that are not executed in the required timeframes, it is nearly impossible to go back and execute the control as it originally should have been. This mistake often requires organizations to either have additional tests performed (to validate the effectiveness via a compensating control) or to acknowledge non-compliance and then revisit the missed requirements in the next year. The necessary level of additional testing or compensating controls required for workarounds is ultimately the decision of the acquiring bank (although a QSA can be extremely helpful in validating an approach), and is typically costly and time-consuming.  

Mistake #6: Not documenting significant changes

Significant changes with an environment are often overlooked, perhaps due to PCI allowing organizations to independently determine what is considered a significant change. The best way to address significant changes to avoid mistakes is to define the term “significant change” in a policy and specify how the organization is applying the policy to its cardholder data environments. Examples of common significant changes often include major security redesigns, architectural changes/additions, firewall rule modifications within the CDE, product upgrades, changes to encryption keys, etc. Once this term has been defined, the organization should ensure all other requirements concerning significant changes within the environment are considered as well, such as performing penetration tests on those changes shortly after they have been completed.

Mistake #7: Service Providers and other Third Parties – Responsibilities Matrix

Organizations decide to outsource certain technologies, people, and/or processes for many reasons. In addition to including internal systems and networks in scope for PCI compliance, all connections from third-party entities to the CDE as well as third parties handling card data on behalf of the merchant need to be identified to determine inclusion for PCI DSS scope. To properly comply with PCI DSS specifications, all applicable requirements must be met, regardless of which entity is ultimately responsible. A service provider is defined by PCI as a “Business entity that is not a payment brand, 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.”   

It is important for both parties to clearly understand which PCI DSS requirements are being provided by the service provider and which are the responsibility of the entity using the service (PCI DSS Requirement 12.8). These requirements and obligations are supposed to be documented between the parties for clarity and consistency. Oftentimes, the responsibility aspect (and/or the documentation thereof) is unintentionally overlooked, which can hinder an entity’s PCI compliance efforts. Please reference the PCI SSC Information Supplement: Third-Party Security Assurance for guidance on management of third-party relationships.

Mistake #8: Control Breakdowns During Turnover

The PCI SSC has published the supplemental guidance “Best Practices for Maintaining PCI DSS Compliance” that highlights one key challenge that we as assessors see quite often lead to compliance concerns in organizations being assessed: turnover of key personnel.

Changes in an organization’s overall management and operational structure can alter the organization’s risk profile as well as the effectiveness of the entity’s PCI DSS compliance efforts. For example, a merger, acquisition, or introduction of a new business line may introduce new payment channels that need to be considered. Similarly, when the organization insources or outsources operational processes, responsibility for certain aspects of PCI DSS compliance activities may shift to a different responsible party (e.g., to a new internal team), and those changes need to be understood and accounted for. Failure to determine how such changes impact an organization’s risk environment and PCI DSS compliance efforts could expose key business functions to security risks or introduce challenges when attempting to comply with PCI requirements.

Other types of organizational changes that warrant consideration can include internal restructuring, corporate spin-offs, bankruptcies and liquidations, and loss of key IT or security personnel. The departure of a key individual who is responsible for executing a number of required PCI controls on a regular basis could result in a failure to operate those controls for a period of time, leading the entity to fall out of compliance with the PCI requirements until the role is filled. Organizations should build in processes for detecting and responding to such changes in a timely manner and establish manual or automated triggers to alert key personnel so any associated risks can be analyzed with due diligence and ongoing control responsibilities can be reassigned. This risk analysis should evaluate the potential impact that the changes may have on an organization’s business objectives, PCI DSS scope, and overall compliance status.

Mistake #9: Vulnerability Management Program Inconsistencies

In a previous post, we covered the importance of performing internal vulnerability scans and described how some organizations struggle to effectively perform the required vulnerability scans on a quarterly basis, include all assets in the scans, and ensure that remediation is performed timely. This requirement continues to be a thorn-in-the-side of some organizations’ PCI compliance efforts.

Ensuring that the CDE scope is accurately defined is critical to the success of complying with this PCI DSS control. When organizations make mistake #1 described above, their vulnerability scans may exclude assets that should have been considered in scope, resulting in an incomplete vulnerability scan. When this occurs, an organization may decide to extend its compliance timeline to allow adequate time to address this requirement so the required four quarterly scans will be available.

The PCI DSS requires that rescans be performed until passing scans are achieved for both internal and external vulnerability scans. The requirement to obtain “clean” scans is one that is sometimes overlooked, especially when an entity’s scans encompass many assets across disparate networks and environments, or when there is turnover within the team responsible for vulnerability scanning.

QSAs will often review HTML exports or PDF exports of an entity’s internal/external vulnerability assessment results to confirm compliance with this control. Because vulnerability scanning tools may periodically delete or overwrite aged scans (and because some vulnerability assessment tools limit the ability to export dated scans), organizations should remember to export out the results of the quarterly vulnerability scans to a designated storage location so they can be accessed and reviewed as evidence of compliance with this requirement.

The PCI DSS are a robust set of security requirements designed to ensure the security of credit card data. Organizations that store, process, and/or transmit credit card data are expected to comply with these requirements. While they can be daunting, an organized compliance program and a specific focus on the most common mistakes noted above will help ensure that your entity’s card data is safe from compromise, and that your organization is compliant with the PCI requirements.

LBMC’s PCI team can help your organization understand and minimize the scope of your PCI cardholder data environment, and help you attain and demonstrate compliance with the PCI DSS requirements in the most cost-effective manner.  Contact Us to learn more.

Content provided by Andy Kerr, Senior Manager at LBMC Cybersecurity.