PCI DSS version 3 is an improved ballast for addressing the protection of cardholder data. Version 3 deltas from previous versions focus on providing a stronger understanding and clarity of the intent and application of PCI DSS test procedures and on driving more report consistency among PCI QSAs. They also provide flexibility to merchants and service providers in the implementation and assessment of the PCI Data Security Standard. Clearly these are noble and much needed revisions; however, a pragmatic look to PCI DSS v3.0 might help us better see its application.
PCI DSS changes in version 3 focus on five major areas:
- Penetration testing
- Inventory of system components
- Service providers
- Evolving malware threats
- Physical access and point of sale
Currently, there is no universally accepted industry standard for penetration studies. Although required by PCI DSS v3.0, the quality, approach and reporting of the pen tests are subjectively reviewed by the QSA and entity being assessed. Despite this, PCI DSS v3.0 requires the development and implementation of a pen test methodology.
- 11.3 – Clarifies requirements for annual internal and external network penetrations tests, and application-layer penetration tests.
- 11.3 – New requirement to develop and implement a methodology for penetration testing. Effective July 1, 2015. PCI DSS v2.0 requirements for penetration testing must be followed until then. This means a penetration test of the CDE must include the analysis of card data flow in electronic form on any system within the CDE and any connected systems.
- 11.3.4 – New requirement, if segmentation is used to isolate the CDE from other networks, penetration tests are to verify that the segmentation methods are operational and effective. This is an interesting one since typically, pen testers have a modicum of knowledge of the environment pen tested. To test segmentation, they now need to know more.
Inventory Systems Components
PCI DSS has always required that entities maintain an inventory of their equipment, software, applications, databases, URL sites, input devices and PAN data storage locations. However, v3.0 is now asking for additional information.
- 11.1.1 – Maintain an inventory of authorized wireless access points including a documented business justification.
- 12.3.3 – Verify that the usage policies define a list of all devices and personnel authorized to use the devices.
In addition to maintaining a list and agreement from service providers to comply with PCI DSS in handling entity cardholder data, version 3 is asking that entities provide proof of compliance and a process to monitor (at least annually) compliance, such as the service provider’s Attestation of Compliance (AOC). This includes maintaining information (12.8.5) about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. Effective July 1, 2015, service providers will be required (12.9) to acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Evolving Malware Threats
Version 3 now states that entities must evaluate evolving malware threats for systems not commonly affected by malware (5.1.2). This includes mainframes (z/OS), mid-range computers (such as iSeries, Tandem, etc.) and similar systems that may not currently be commonly targeted or affected by malware. The mainframe and mid-range computing environments have long since and continue to be a critical PCI DSS cardholder environment (CDE). Unfortunately, QSAs that truly understand z\OS, virtual storage protection, RACF\ACF2\TopSecret internals are few in number. Threats to CDE and CHD in these environments are much more expansive than malware but a good start.
Physical Access and Point of Sale
Physical access controls of in-scope office locations, data centers, storage sites and retail store locations are standard in PCI DSS assessments. Version 3 is now requiring that entities protect (9.9) devices that capture payment card data via direct physical interaction with the card from tampering and substitution. This new requirement will be a challenge at retail stores, onsite merchant locations, gas stations, etc. Corporate offices will be easier to handle but where there is no badge access, changing door locks whenever an employee terminates might be an expensive proposition.
Maintaining an up-to-date list of devices (9.9.1) by make, model, location and serial number sounds reasonable. However, effective 1 July 2015, this new requirement to protect point-of-sale devices (9.9.2) will require periodic inspection of device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). Admittedly this is a great idea, but we need to understand that now retail personnel, typically hourly employees, will need to be trained on how to detect device tampering.
This past year has taught us a major lesson. Malware infections, state sponsored attacks, APT, including the not-so-talked-about internal frauds, will continue to happen with increased frequency, many of which could be avoided with prudent deployment of controls. Admittedly, PCI DSS will not prevent such occurrences, but if properly deployed is an effective mitigant that seemingly improves with every version.
Blog size limitations preclude further comment on noteworthy version 3 changes, but overall they appear to provide for better CHD protection. The five major changes listed here are to raise awareness and possibly postulate on the preparatory work needed for version 3 compliance. There are clearly some challenges that will arise, but none that would prevent us from formulating proper remediation and compliance.
Miguel (Mike) O. Villegas, CISA, CISSP, CEH, GSEC, PCI-QSA, PA-QSA, ASV
Vice President, K3DES LLC