24
Sep
13

Coming Attractions

On September 12, 2013 the PCI SSC released the drafts of version 3 of the PCI DSS and PA-DSS.  In reviewing the PCI DSS, there are six new requirements that will be considered ‘best practices’ until July 1, 2015 when they will become requirements.

  • 6.5.6 – Insecure handling of PAN and SAD in memory.
  • 6.5.11 – Broken Authentication and Session Management
  • 8.5.1 – Service providers with access to customer environments must use a unique authentication credential (such as a password/phrase) for each customer environment.
  • 9.9 – Protect point-of-sale (POS) devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
  • 11.3 – Develop and implement a methodology for penetration testing that: is based on industry-accepted penetration testing approaches (for example, NIST SP800-115), includes coverage for the entire CDE perimeter and critical systems, includes testing from both inside the network, and from outside of the network attempting to get in, includes testing to validate any segmentation and scope-reduction controls, defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5, defines network-layer penetration tests to include components that support network functions as well as operating systems, includes review and consideration of threats and vulnerabilities experienced in the last 12 months, and specifies retention of penetration testing results and remediation activities results.
  • 12.9 – Additional requirement for service providers: Service providers acknowledge in writing to customers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer’s cardholder data environment on behalf of a customer.

I will discuss requirements 6.5.6 and 11.3 in separate posts.  I am not going to discuss 6.5.6 until I have a better understanding of how the PCI SSC expects QSAs to test that memory is being managed properly.  I am avoiding 11.3 because it contains enough for a post of its own.  But the others can be addressed in this post.

First, I have to say that I was amazed that these actually had to be codified as they are addressed through a number of other requirements.  But having run into numerous instances where I have encountered these situations, I understand why the PCI SSC felt the need to explicitly codify them.

For requirement 6.5.11, the guidance provided states:

“Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user. “

This requirement is targeting the botnets and Trojan attacks such as with Citadel and Zeus.  The problem here is that these are attacks on the end user, not the merchant.  As a result, what this new requirement is going to likely be looking for is for the merchant to be using methods to secure authentication and communications such that man-in-the-middle, man-in-the-browser and similar attacks are minimized or even eliminated.  It will be interesting to see how the PCI SSC expects this to be accomplished.

It has been a long time coming for 8.5.1.  Most QSAs have encountered this situation and we never liked it.  The situation that I speak of is managed service providers and software vendors using the same user identifier and password for all of their customers which they support.  While one can appreciate why this occurs, it does create a problem should those common credentials become known outside of the organization which has been the case in a number of breaches.  As a result, the PCI DSS has been changed to include this new requirement to require managed service providers and software vendors to use unique authentication credentials with each customer.

Requirement 9.9 is to explicitly address a best practice that has been used by a lot of merchants.  A number of merchants have experienced the tampering of card terminals over the years.  This typically was in the form of soldering a USB thumb drive or SD card into the terminal to collect track data and then replacing a good terminal with the doctored terminal at the merchant.  This threat is typically mitigated by video monitoring of terminals as well as the use of serialized security tape or tamper evident seals over a terminal’s case seams that is checked at least daily to ensure that terminals have not been changed out or tampered with.

And finally, requirement 12.9 calls out that service providers explicitly acknowledge in a document that they will maintain compliance with the PCI DSS for all relevant services.  Apparently the existing requirements in 12.8 were not providing enough assurance that service providers were complying with the PCI DSS.  So now we are going to require that all service providers acknowledge, in writing, that they will maintain compliance with all relevant PCI DSS requirements for all services provided to their customers.

Advertisements

8 Responses to “Coming Attractions”


  1. 1 Neon
    January 13, 2015 at 1:56 AM

    What is the difference between 12.9 and 12.8.2? If the entity is service provider does 12.9 ask the entity to have agreement with customer regardless of the customer require an agreement or not?

    • January 18, 2015 at 8:39 AM

      All parties that have access to cardholder or sensitive authentication data (CHD, SAD) should have mutual legal agreements in place that state they will protect that data as required by the PCI DSS. The difference in v3 is that the PCI DSS is now explicitly requiring that service providers state they will protect the data per the PCI DSS. The Council and the card brands felt that service providers were not legally on the hook enough which is why they added the requirements.

  2. January 22, 2014 at 5:07 AM

    Hi,

    It seems that “6.5.6 – Insecure handling of PAN and SAD in memory” has disappeared in the official PCI DSS 3.0 version…

    It has been replaced by a unclear guidance “As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks.”

    With the recent breaches with BlackPOS, it would be a great improvement from the SSC to emphasize this risk.

    • January 25, 2014 at 11:05 AM

      It did not totally disappear. It is now included in requirement 6.5.c.

  3. 5 Dave
    October 14, 2013 at 3:37 PM

    On 8.5.1, would this prevent a service provider from developing a system where an ISO admin would have access to all of the merchants below him in a hierarchy? Suppose he is not logging into the terminal system they use, but a management system designed to help maintain and support many merchants? How would 8.5.1 affect an ISO that has a management console that gives him access to a read-only version of many customers environments?

    • October 19, 2013 at 6:24 AM

      What the PCI SSC and the card brands are trying to stop are the service providers that use the exact same credentials with all of the customers to obtain remote access, read-only or not. According to the forensic findings from a number of breaches, those breaches were caused by the fact that the “bad guys” could log into a number of merchants and then use that to gain access to cardholder data through the service providers’ maintenance accounts.

      What 8.5.1 will require is that service providers implement an enterprise password vault solution so that different credentials can be easily managed for each customer.

  4. 7 Biju
    October 2, 2013 at 7:23 AM

    I was at the council meeting and the Council’s exception on 6.5.6 is to have a training program for developers. They are not expecting QSA’s or ISA’s to test it

    • October 6, 2013 at 9:53 AM

      At the QSA/ASV session on Tuesday afternoon, they explained the two tests that they expect QSAs to perform. One is to interview developers and ask if they securely manage memory. The second was to observe the techniques used to securely manage memory. Most of the people in the room bemoaned the fact that this sort of testing is late in the game and meaningless.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

The PCI Guru will be LIVE on Wednesday, May 17, with the "PCI Dream Team" to discuss your worst PCI compliance issues. Go to https://www.brighttalk.com/webcast/288/245165/all-your-pci-questions-answered-interactive-q-a-with-the-pci-dream-team to register for this event.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2013
M T W T F S S
« Aug   Oct »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,814 other followers


%d bloggers like this: