The release of PCI DSS version 3.1 earlier this year brought renewed attention to the compliance programs merchants and service providers built around their electronic payment security infrastructure. Justifiably, the majority of that attention focused on the retirement of SSL and early TLS protocols as valid encryption methods for sensitive cardholder information. Flaws in these encryption protocols undermined security and demanded an immediate fix. Merchants and service providers around the world scrambled to identify uses of the outdated technology in their environments and find suitable alternatives.
The deprecation of SSL/early TLS encryption wasn't the only change in PCI DSS this year. Several smaller changes that require the attention of merchants and service providers took place as well. Some of these are due to the expiration of grace periods for compliance with new requirements, while others were contained in the new PCI DSS 3.1 revision. Organizations seeking to maintain PCI DSS compliance may wish to review the SSL changes and the set of requirements that went into effect earlier this year. With that knowledge under your belt, let's take some time to review two of the new requirements.
Every PCI DSS compliance professional knows merchants and service providers must run quarterly PCI vulnerability scans of their internal and external networks to probe for security vulnerabilities. They must then promptly remediate any vulnerabilities the scans detect and document the results of a new scan until they obtain a clean, passing report. In PCI DSS 3.0, the guidance to Qualified Security Assessors (QSAs) stated that an acceptable scan consisted of an "automated tool run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals."
You'd be hard pressed to find an organization that doesn't use an automated scanning tool due to the complexity of PCI vulnerability scans. However, the PCI Security Standards Council updated the guidance language to clarify that the scans may also use manual tools. The new language describes a vulnerability scan as a "combination of automated or manual tools, techniques and/or methods run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals."
What does this mean to the typical organization? It clarifies that vulnerability scans may incorporate the use of manual testing procedures. The most likely scenario for this scan might be when an organization performs the required remediation of existing vulnerabilities. The new language seems to offer an alternative to running a completely new scan. An organization might remediate a vulnerability and then perform manual testing to confirm the remediation and submit the results of that manual verification along with the results of the automated scan to meet their documentation requirements. While many organizations would consider it easier to simply run a new automated scan, this approach might help in the case where an organization simply forgot to run the second scan within the required timeframe and instead is pulling together available documentation from earlier tests to meet the requirement.
Protecting POS devices
One of the major changes that took effect on June 30, 2015 is a set of new requirements covering the physical security of point-of-sale (POS) devices. These requirements mandate the use of inventories, inspections and training to protect these devices from tampering or unauthorized replacement. The requirements respond to the risks posed by skimmers that unauthorized individuals would install on legitimate POS devices to surreptitiously collect payment card information.
PCI DSS version 3.1 provides some additional guidance to QSAs regarding the inventory verification requirements surrounding POS devices. Merchants must continue to maintain an inventory that includes every device that comes into physical contact with payment cards. That inventory must include the make and model of devices, along with each device's serial number and physical location. Under PCI DSS 3.0, QSAs were required to use sampling to verify the inventory against physical devices. The PCI DSS 3.1 update adds two words to this requirement, which now reads: "Select a sample of devices from the list and observe devices and device locations to verify that the list is accurate and up to date."
The change here simply clarifies that observation of the device location is not sufficient, and QSAs must also physically inspect devices to match the make, model and serial numbers against the inventory list.
PCI DSS version 3.1 changes: What you need to know
These two changes that come in PCI DSS version 3.1 don't have the same magnitude as the deprecation of SSL/early TLS encryption, but they are important nonetheless. Merchants and service providers subject to PCI DSS should take the time to thoroughly review the PCI DSS 3.1 summary of changes and ensure they remain compliant with the updated standard.