By Chris Camejo, Director of Assessment Services, NTT Com Security

Version 3.0 of the PCI Data Security Standard (PCI DSS) goes into effect by the first of next year, and it probably doesn’t come as a surprise that merchants that process credit card payments are still confused about what the changes mean for them.

While most of the changes are simple clarifications of previous requirements, they could have a major impact on merchants as they touch on everything from the definition of scope and segmentation, to formally documenting responsibilities between merchants and service providers and controls for preventing tampering and skimming at the point-of-sale.

The scope definition has always been one of the thorniest issues within PCI compliance. Many merchants will say they are compliant simply because they ran a vulnerability scan on a handful of credit and debit card data systems. But performing an external vulnerability scan is just one sub-requirement out of over 200 in the PCI DSS.

Additionally, by only focusing on the systems that actually handle credit card data, you’re ignoring all of the other potentially vulnerable servers and workstations that share a network with the credit card processing systems, which should be included based on the way the scope is defined within PCI DSS.  It’s not necessary for attackers to go directly after the systems that contain credit card data, especially because most companies have a “flat network” where only the Internet connection is guarded by a firewall and every server has the ability to communicate without going through a firewall or other filter.  That means attackers just need to find the easiest way to breach the network perimeter, which helps explain why we see so many phishing attacks that trick a user into running malware that opens a backdoor into their device. The attacker can then use the compromised device to launch attacks on the credit card processing systems from behind the secured perimeter.

For this reason, PCI DSS compliance is required on systems including those that actually handle card data, all the unrelated systems that connect to the same network, and the systems that can affect their security (authentication servers, firewalls, web redirection servers, etc.). This has been clarified and made explicit in the scope section of 3.0 and may come as a shock to merchants that have only addressed compliance on the systems that directly handle card data.

Segmentation

PCI encourages merchants to implement network segmentation by using firewalls to protect their card data systems from unrelated and non-complaint servers and workstations, thereby keeping them out of scope. However, there is a concern that ineffective segmentation can lead to a false sense of security and inaccurate scoping.

The new 3.0 version requirement 11.3.4, effective July 2015, requires annual penetration tests to validate that the segmentation methods are “operational and effective.” I suspect a majority of merchants will find their segmentation isn’t as effective as they thought and may need to tighten the screws on their firewalls as a result.

The PCI compliance scope also involves any third-party that could affect the security of, or handles card data on the behalf of a merchant. It could be a datacenter that hosts the servers, a managed service provider that controls the firewalls, or a support service with access to a database full of credit card data.

Since service providers don’t directly handle credit card data themselves, they may try to disclaim any and all responsibility for PCI compliance, leaving the merchant in an untenable position. Even if a third-party service provider controls some critical aspects of your PCI compliance, that party won’t take responsibility for potential consequences should your customers be breached.

The recent Target point-of-sale breach provides validity of this concern, the attack was believed to have originated from a compromised HVAC contractor.

To address finger pointing in the aftermath of a breach, PCI DSS 3.0 has new requirements for merchants and service providers. Both parties are now required to formally document who is responsible for which PCI requirements (12.8.5). Additionally, service providers must acknowledge their responsibility for PCI compliance (12.9), effective July 2015.

Despite these requirements, getting some third parties to agree to responsibility may be akin to pulling teeth.

Another major concern is tampering with physical point-of-sale devices. Effective July 2015, a new PCI requirement (9.9) calls for an inventory of devices and regular inspections to detect tampering.

Tampering is often a problem at gas station pumps, ATM machines and manned cash registers with checkout terminal PIN pads because skimmers and hidden cameras can be installed on devices. Aldi Supermarkets, Michaels Craft Stores and Barnes & Noble have all suffered breaches as a result of tampering.  This new requirement can be misinterpreted to mean that point-of-sale devices need to be locked to an immovable object. Locking the device is not required; merchants need to focus on inspecting the devices for signs of tampering regardless of whether or not they are locked.

The January 2015 deadline for assessing under version 3.0 is around the corner and although some of these requirements do not go into effect until July 2015, merchants need to understand the definition of scope and segmentation, begin working with service providers to define responsibilities and potentially alter contracts, and implement controls for preventing tampering and skimming at the point-of-sale devices.

Merchants should keep in mind, the rest of the PCI DSS 3.0 requirements will be validated during their first SAQ or QSA assessment in 2015, however it’s best to start addressing the necessary changes immediately. Merchants can consult with a QSA company or attend PCI-run training class to explain the requirements.

At the end of the day, merchants need compliance across all systems, not just the one that directly handles credit card data, or they could be the next company announcing a security breach.