Your browser is out of date.

You are currently using Internet Explorer 7/8/9, which is not supported by our site. For the best experience, please use one of the latest browsers.

866.430.2595
Request a Consultation
banner

PCI Guidance for Penetration Testing & Mobile Payment Applications: Sept 2017 Cerberus Sentinel Blog

Last week, the PCI council published updated guidance on Penetration Testing and Mobile Payment Applications.  Here is a quick overview of the relevant changes in each and how it may affect merchants and service providers moving forward.

Penetration Testing

While there were no significant changes to the original pen-testing guidance from March 2015, a few small changes were made.

  • PCI has now clarified the term “social engineering” as it relates to network pen-testing.  While PCI-DSS does not require a social engineering component for compliant pen tests, they do note that it can be a valuable and effective method of identifying risks associated with end-user failure to follow documented policies, specifically as a way to introduce malware into an environment.  Finally, PCI recommends that merchants and service providers document their reasoning for foregoing social engineering testing, particularly if social engineering attacks were encountered by the organization within the last 12 months.
  • In section 2.2 of the updated penetration testing document, PCI has broken out scoping considerations for the four major areas (internal, external, segmentation, & critical systems) of pen testing in the context of PCI.  While none of the information is new here, the document is now much clearer on what to consider when scoping in these four areas.  This section is particularly helpful in defining the difference between external and internal testing, as well as how to define a “critical system.”
  • The final notable change to the guidance is around black-box testing and back-end APIs. Previously, PCI guidance didn’t clarify much on white vs. gray vs. black box testing and which would make the most sense in context for PCI.  They have now added some points on why it is preferable to do white or grey box testing with the idea being that these assessments provide more accurate results and a more comprehensive test overall. For back-end APIs, PCI is now stating that the API may be in scope for testing for web applications that utilize back-end calls. PCI is relying on the tester's understanding of the interaction between the web app and the API to decide if it warrants testing. 

A final reminder too, PCI will be requiring, as of February 1, 2018, that service providers (not merchants) undergo semi-annual segmentation control testing in addition to the yearly requirement for regular penetration testing.

More details can be found in the Penetration Testing Guidance Information Supplement, Version 1.1

Mobile Payment Applications

As mobile payment platforms are becoming more common place, the previous guidance from PCI published in 2013 needed a major refresh.  The document published last week goes a long way in helping merchants understand what types of risks are involved with accepting payments on a mobile platform, as well as clarifying what merchants should do to better secure these systems.  Here are some of the highlights of the new guidance document:

  • PCI specifically states they do not recommend merchants utilizing any devices for payments that are not managed or controlled by the merchant themselves. Since BYOD (bring your own device) scenarios are becoming more commonplace, merchants should outline what should and shouldn’t be allowed with mobile devices to include payments that merchant employees receive on behalf of the merchant. In other words, employees should not be taking payments on behalf of merchants on their personal devices.
  • PCI outlines three major objectives for the security of a payment transaction:
  1. Prevent account data from being intercepted when entered into a mobile device - This objective covers protecting cardholder data when inputting it into a mobile device, including validating hardware and software where cardholder data is input.
  2. Prevent account data from compromise while processed or stored within the mobile device - This objective covers the assurance that only trusted individuals have access to the payment application and its environment.  Additionally, PCI recommends secure storage of mobile devices when not in use and to secure internal networks that transmit the cardholder data (PCI-DSS Requirement 4).
  3. Prevent account data from interception upon transmission out of the mobile device - This objective covers wireless security such as changing default passwords and encryption keys on devices and not allowing clear text data transmission for payments.
  • The other main portion of the document goes into more specifics about securing mobile devices and the applications themselves.

Guidance for securing the devices covers the following topics:

  • Unauthorized physical access
  • Unauthorized logical access
  • Protecting the device from malware
  • Ensuring the device is in a secure state
  • Disabling unnecessary functions on the device
  • Detection of loss or theft of the device
  • Disposal of old devices

Guidance for securing the applications on the mobile devices includes:

  • Implementing secure solutions
  • Ensuring the secure use of the payment-acceptance solution
  • Preferring online, instead of offline or batched, transactions
  • Unauthorized usage prevention
  • System logs and report inspection
  • Ensuring that customers can validate the merchant/transaction
  • Issuance of secure receipts

More details can be found in the PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users, Version 2.0

Ask A Question