One would think that the publication of the next version of the PCI DSS (April 2016) as well as the sunset date of the previous version (in October 2016) would constitute a pretty full year for PCI. However, the end of 2016 and beginning of 2017 saw a flurry of activity from the PCI Security Standards Council (PCI SSC), specifically around their Guidance Documents.

The following Information Supplements were published in the last year:

• Assessment Guidance for Non-Listed Encryption Solutions (November 2016)
• Guidance for PCI DSS Scoping and Network Segmentation (December 2016 & May 2017)
• Multi-Factor Authentication (February 2017)
• Best Practices for Securing E-commerce (April 2017)

While there is too much detail in each document to cover everything here, I’ve tried to summarize the information provided by each document and add any commentary that may help you understand the details in each supplement.

Case studies are included in each document in addition to the official guidance. The case studies are not exhaustive, but they do help illustrate (literally) how the information in the supplement applies to real world scenarios. They are simple and relatively easy to understand.

Note that these documents do not have the same weight of the PCI DSS. As the Council clearly states:

The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in any PCI SSC Standard.

The primary value in these supplements is the insight into how the Council is approaching security controls, to help security practitioners extend the official intent statements for certain requirements, and possibly to signal where there is concern of potential risk from a group privy to breach and forensic reports.

Assessment Guidance for Non-Listed Encryption Solutions

Version 1.0, November 2016

End-to-end encryption (E2EE), properly performed, delivers data over a secure connection from point-to-point (hence the PCI Council’s P2PE designation). It helps reduce the attack surface and minimize the risk of insecure touch points. In the payments industry, this has typically been implemented as a way to accept payment data from your customer and deliver it securely to your acquiring institution while getting rid of the intermediate step of storing non-tokenized cardholder data.

The PCI SSC introduced the PCI P2PE program in 2011 to define the requirements for vendors, assessors, and solution providers to follow for P2PE certification, “with the goal of reducing the scope of the PCI DSS assessment for merchants using such solutions.” A reduction of scope of the annual PCI DSS assessment work can be a huge benefit. With a validated P2PE solution in place, the validation process can potentially be reduced to physical security and governance.

The adoption of the P2PE certification was initially slow and seemed to stem from pre-existing solutions that didn’t align with the standard and an overly complex compliance regimen. The passing of time and publication of P2PE v2 seems to have helped increase the number of validated solutions. But there are still payment solutions that have not assessed their solution with the voluntary certification process but do take security seriously.

Enter the Assessment Guidance for Non-Listed Encryption Solutions supplement. This document provides guidance in approaching end-to-end encryption solutions that have not gone through the P2PE certification process. Understandably, the “adoption of a PCI-validated P2PE solution is strongly encouraged” by the PCI Council. Previously, non-listed solutions could be used for scope reduction and meeting PCI requirement but required additional review during each assessment. Now there is a process, published by the PCI Council, that allows for evaluation of a non-listed solution.

Merchants considering a new E2EE solution that meets the following description will benefit the most from understanding the process in the document:

• PCI-listed PTS POI v2 (or higher) devices
• No access to encryption/decryption keys
• No access to clear-text account data transmitted outside the device

However, similar to the P2PE certification, this formal process is not a solo effort and requires participation by Acquirers, Solution Providers, P2PE QSAs, and QSAs. The swimlane diagram in Section 1.6 illustrates the process flow and involved steps.

The process includes the production of a P2PE Report on Validation (P-ROV) and a Non-Listed Encryption Solution Assessment (NESA) Report - essentially reviewing the same details reviewed during a P2PE Assessment. This is not a small level of effort and will likely result in many of the same complexities as certification. Ultimately, the Solution Providers will need to understand if the benefit of having the additional validation performed is important for their potential customers.

Don’t miss Section 6 which provides a high-level checklist for POI devices that can help a merchant or QSA quickly evaluate a technical solution against some of the more important portions of Domains 1-3 in the P2PE standard.

Guidance for PCI DSS Scoping and Network Segmentation

Version 1.0, December 2016
Updated to Version 1.1, May 2017

Most organizations attempt to limit the environment that is considered in scope for PCI Assessments, usually using network segmentation. This helps reduce the access to cardholder data by the rest of the organization and increases the security of the data. It can also help ease the compliance burden and reduce the level of effort required during assessments by both the security teams and the assessors.

Unfortunately, it seems the segmentation implementation is not always as secure as intended:

A common pattern seen in data breaches is where the attacker targets systems deemed by the entity to be out-of-scope for PCI DSS, then leverages those systems to gain access to more systems, which eventually provide a path to systems where CHD data can be found.

This guidance document provides a model for defining the system type (or category) and the related scope and applicability. The table on pages 11 & 12 has all of the details.

The three classes of systems defined are:

• CDE Systems
• Connected-to and/or Security-Impacting Systems
• Out of Scope Systems

Cardholder Data Environment (CDE) systems are relatively easily defined as those that store, process, or transmit cardholder data or systems on that are on the same network segment as those that do. Out of Scope systems are essentially the opposite.

Connected-to and/or Security-Impacting Systems, however, have a longer list of conditions. Any of the following can cause a system to be classified in this category:

• System component is on a different network (or subnet or VLAN), but can connect to or access the CDE
• System component can connect to or access the CDE via another system—for example
• System component can impact configuration or security of the CDE
• System component provides security services to the CDE
• System component supports PCI DSS requirements
• System component provides segmentation of the CDE from out-of-scope systems and networks

The takeaway here is that any of these “Connected-to” systems must be in scope for PCI, must be evaluated against all PCI DSS requirements to determine the applicability of each requirement, and must not provide an access path between CDE systems and out-of-scope systems. If for some reason you have systems that have not been included in past assessments that meet this criteria, make sure that you do a proper evaluation on their security configuration and correct the official scoping before your next assessment.

Ten pages are also devoted to two very common scenarios: “Connected-to” Shared Services and CDE Administration Workstation outside of the CDE. Shared Services are common in organizations looking to leverage services such as Directory and Authentication, NTP, DNS, SMTP, Monitoring, Scanning, Backup Tools, Anti-Virus and patch deployment servers, etc. The second scenario, Admin Workstations outside of the CDE, is common in most organizations who have a corporate office network logically separated from their production network (and everyone with remote admins).

If these classes sounds familiar, there is a reason. Many organizations have been using a system like this for many years. A very similar category terminology was introduced by the Open PCI DSS Scoping Toolkit. The toolkit also provides a decision tree for deciding what category a system is as well as quite a few scenarios (including a couple that align with the two in the guidance document).

The Guidance for PCI DSS Scoping and Network Segmentation provides additional clarity from the PCI Council’s perspective on the definition of a “connected-to” system and instruction on how scoping and PCI DSS controls should be taken into consideration.

Multi-Factor Authentication

Version 1.0, February 2017

Version 3.2 of the PCI DSS introduced a new requirement (8.3.1) to enforce multi-factor authentication (MFA) for any non-console administrative access to the cardholder data environment. The new requirement is considered a best practice until February 2018. Previously, this control was limited only to remote network access (a control which has not changed, just renumbered as 8.3.2).

It is not surprising to see this control moved closer to the CDE due to the privileged access afforded these logins and the disappearing edge of corporate networks. Additionally, requiring another factor lessens the sole dependence on passwords. Given the number of password data breaches that have occurred, the prevalence for reuse, and our shortcomings as humans to create strong passwords (that we don’t write down on Post-Its), adding MFA is definitely an improvement for an organization’s security posture.

The PCI Council uses the standard definition of MFA. It must use at least two of the following:

• something you know
• something you have
• something you are.

The document does point out that other types of information, such as geolocation or time, can be used for authentication but not counted towards the required number of methods. This is a salient point, as this type of data is being used more often by organizations as a part of fraud detection and unauthorized activity methods and will be accessible more often by security teams.

Additionally, the methods used must be independent. When designing a MFA solution, ensure that use of the first factor, such as credentials or biometrics, does not also allow for access to the second factor, such as certificates or one-time password (OTP) on an out-of-band (OOB) device.

NIST came out last year and answered the question few were asking - SMS for authentication is now discouraged and being considered for deprecation. While the authentication is not prohibited yet, the Information Supplement does send a message to be aware. If you are currently using SMS, you will still be able to be compliant with the PCI DSS. There are no guarantees from the PCI Council that stance will not change in line with NIST.

Organizations also need to consider the difference between multi-step and multi-factor. A Multi-Factor Authentication solution should require all factors, without prior knowledge of the success or failure of specific factors, before granting access. For example, if you must submit a correct password before being prompted for your thumbprint, the guidance considers this to be multi-step authentication.

The discussion of cryptographic tokens lines itself up with NIST Special Publications 800-157 and 800-164. Hardware cryptographic modules are plainly preferred over software modules, but either is acceptable when following the best practices.

As with any credentials, all authentication mechanisms should be protected. It sounds cliche to remind security professionals not to share their password at this point. But many typically do not think about protecting their biometrics or a token with the same type of eagerness. Thankfully, most of us notice a missing phone immediately these days.

A review of the common authentication scenarios used in the case studies seems to imply the largest concerns are unsecured credentials on devices or reused credentials in multiple steps of authentication not yielding true Multi-Factor Authentication. The illustrations could use a little more detail showing what is accepted versus prohibited. Don’t just read this section for the pictures, dig into the verbiage to fully understand the message.

Overall, guidance in the Multi-Factor Authentication Information Supplement is a nice collection of generally accepted industry practices. With many organizations considering how to meet the new requirements before February 2018, this seems to be a precautionary reference tome.

Best Practices for Securing E-commerce

Version 1.2, April 2017

This document has two distinctions from the rest of the crowd. It is the only one of the four documents that is a revision of an earlier Information Supplement. It is also the only one compiled through contributions of a Special Interest Group (SIG) and not solely by the PCI Security Standards Council. The participating vendors and service providers (over 80 of them) have both subject matter expertise and a specific reason they are participating organizations and members of the SIG.

As a whole, the refresh definitely highlights changes to e-commerce solutions in the marketplace. Gone is the discussion of the generic three-tier e-commerce infrastructure. The method of implementation plays a more important role in the new document. Merchant-managed applications as well as shared-management implementations (redirects, iFrames, APIs, etc.) are the basis for the new structure. This should serve merchants well as they can hone in on the model they are using (or thinking about using) and quickly determine the impact and recommendations.

Speaking of impact and recommendations - one of the slides that drew my attention at last year’s PCI North America Community Meeting shows up in a modified form as the PCI DSS Documentation Requirements by E-commerce Method chart. This, along with the Advantages and Disadvantages of E-commerce Methods chart, are a powerful, if qualitative, look at the impact of the different types of hosted e-commerce solutions. These are a great resource if you are outsourcing e-commerce transactions or wondering if there’s a difference in compliance impact for different types of e-commerce methods.

There is also a good discussion of e-commerce in conjunction with other cardholder data flows. While some companies operate as an e-commerce only shop, many are a mix of payment functions, including telephone orders, refund requests, and chargebacks.

A long list of suspicious activities for security and fraud controls is provided in Section 2.11. Review carefully - if you aren’t considering monitoring these activities, you are missing out on the ability to alert on questionable activity in your environment.

Completely new in the document are two sections on public key certificate selection as well as the encryption and certificate types. This is more detail than we’ve seen in the past from the Council on SSL/TLS, but posed more as a how-to primer than specific security controls.

Completely missing is the common vulnerabilities in e-commerce environments section from the 2013 version. This section included several of the OWASP Top 10, a proven source of attack vectors. It seems odd to leave out a section whose vulnerabilities are still a staple in penetration test findings and a major contributor to many data breaches.

The Best Practices section has only been lightly changed. The previous version discussed risks associated with service providers but that section is now boiled down to just service provider remote access. A penetration testing section is added but is only focused on merchants using third party e-commerce solutions. The payment applications section is expanded and includes recommendations for networking, applications, and monitoring.

In Conclusion

The PCI Council does not have the bandwidth to author Information Supplements about every security topic or technology, so it’s reasonable to assume a level of importance about the topics they choose. It may be because they are related to upcoming changes or potentially an outcome from recent breaches. Understanding the content of these recent documents helps fill in blanks behind the intent of the PCI Standards. It is important, though, to remember that they aren’t considered letter of the law. Hopefully this summary helps you to understand where the topics in each document aligns with your security and PCI programs.