New version of PCI DSS released (v3.2)

As you may be aware the security issues relating to SSL and early TLS prompted the Payment Card Industry Security Standards Council (PCI SSC) to issue a new version of the Payment Card Industry Data Security Standard (PCI DSS) and supporting documents.  This release v3.1 (April 2015) included a deadline for moving away from SSL and early TLS by June 30, 2016.  

After the release of version 3.1 of the standard, the industry as a whole provided feedback to the council regarding the deadline of this particular requirement and late 2015 the deadline for removal of these protocols was extended to June 2018.  The council has now formalised this in a new version of the standard. There are however a number of other changes that have been introduced in this new version that you should be aware of and that will affect your compliance requirements, especially for service providers.  
The new release of the standard is effective immediately, version 3.1 will be retired October 31, 2016. This means that your next assessment will likely be against the new version of the standard.

The new version of the standard has a number of new requirements.  These are considered best practice until 1 February 2018, which means that you are encouraged to implement them as soon as possible, but they must be in place by the deadline.  For those of you still using SSL or early TLS, there are a number of new requirements outlined in appendix 2 of the standard that must be in place, effective by June 30, 2016. Most of you will already have these, with the possible exception the requirement to have “All service providers must provide a secure service offering by June 30, 2016”.  This particular requirement recognises that many service providers have customers that may not be able to change their systems to remove the weak protocols by June 30, but ensures that service providers have the capability to accept the stronger protocols. This should only affect you if you have systems that cannot communicate using TLS v1.1 or preferably TLS v1.2.

The highlights of the changes are as follows:

  • 3.5.1 – Maintain a documented description of the cryptographic architecture.
    This applies to service providers only and is something Shearwater has been encouraging clients to do for a while now.  The requirement outlines what information is required.
  • 6.4.6 – Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
    Whilst this was always implied in the standard this version calls it out as a specific activity and is designed to ensure PCI DSS compliance is part of BAU rather than an annual activity. For the majority of you this will be an additional step in the change control process, however it will now be an auditable event. The guidance for the requirement provides information on what is expected for this control.
  • 10.8 – Implement a process for the timely detection and reporting of failures of critical security control systems
    This relates to reporting of failures within the organisation. There must be processes place to detect failures with security controls and processes to address them. Similar to an incident response plan.  
  • – Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
    This testing can be done by qualified internal resources or a qualified third party.
  • 12.4 – Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program.
    Most will already have this, but the standard is now enforcing it.  PCI compliance must now be assigned to a specific role.  
  • 12.11 – Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.  
    This requirement again goes towards ensuring PCI DSS compliance is an ongoing process rather than a once per year activity.  Many of you will have this already.  It basically requires you to have processes in place that once per quarter validates that daily tasks etc. are being performed.  

Two new appendices are in place. Appendix 2 as mentioned previously outlines the SSL and weak TLS requirements.  The final appendix addresses requirements for those that are explicitly told they must do this. This is based on volume and other criteria.  
A few requirements have been removed as the item was generally already covered by another requirement.  

The only other requirement that could have a significant impact is the changes to requirement 8.3.  this requirement currently requires two-factor (now changed to multi-factor) authentication when administering the Cardholder Data Environment (CDE) remotely.  This has now been changed that ALL administrative access must be multifactor authentication.  This could be any form of multifactor authentication, but potentially this will have an impact on how you manage the CDE and CDE components.  

Other changes in the standard are cosmetic. Clarifications for a number of requirements are provided, some dated examples are removed. The council’s “Summary of changes document from PCI DSS version 3.1 to 3.2” ( outlines all of the changes.  

It is recommended that you have a read of the summary of changes document.  As always should you have any further questions feel free to reach out to your Shearwater contact, or directly to myself.  We can certainly help you navigate the requirements.  

I Think I Need to Be PCI Compliant… Now What??

By Heather Robins

Sometimes, coming to grips with your company’s need to be compliant with the Payment Card Industry Data Security Standards (PCI DSS) feels a bit more like going through the Five Stages of Grief than tackling a standard issue business problem. I’ve been in the Information Security industry for a little over 5 years, and I’ve heard just about every justification and excuse about why (insert excuse here) means your business doesn’t need to comply with the standard… but if your organisation processes, stores or transmits credit card data (yes, any one of those things!), then yes, you DO need to comply with the PCI standards.

If you’ve arrived at this page, the good news is it’s likely that you’ve finally reached the ‘Acceptance’ phase of your journey. The bad news is that this is where the work begins!

The steps outlined below are just that – an outline. This may or may not apply precisely to your business, but it should start you on the right path. Your acquiring bank should be able to provide additional assistance and if you want additional assistance, reach out to a Qualified Security Assessor in your region (Shearwater can help in Australia).

Step #1:

Define your Cardholder Data Environment and Document Your Card Flows. In simple terms: how do you accept credit cards, what do you do with them and how.  

Step #2:

Look at that scope you just defined… is there any way to limit it? Can you eliminate a business process that currently requires you to store credit card numbers in Manny from Finance’s bottom drawer? Can you segment your environment at this point? A limited scope and limited number of card flows will save your sanity.

Step #3:

Understand if you’re a Merchant or Service Provider and What “Level” you’re at. This is a question of how your business interacts with cards and how many interactions it has with cards. PCI DSS doesn’t care if you take one credit card number and process it 6 million times or take 6 million cards and process them one time, if you’re over 6 Million transactions per year, you are a PCI DSS Level 1 Merchant.   The Level 1 barrier for Service Providers is at 300,000 transactions per year. Level 1 (for either Merchant or Service Provider) means you’ll need to engage a Qualified Security Assessor (QSA) organisation… the silver lining is you won’t have to fill in a Self Assessment Questionnaire because your QSA will do that for you, in the form of a Report on Compliance (RoC) and an Attestation of Compliance (AoC).

Step #4:

Find Your Self-Assessment Questionnaire (SAQ). If you are not a level 1 Merchant or Service provider you will need to complete an SAQ. While I’ll be looking to write a bit more extensively on picking your SAQ, the best first step is to look at the PCI Council’s Website. There are specific SAQ’s to fit specific business models (ecommerce only, virtual terminals only, etc.) The short story is SAQ D covers just about everything so, if you know you take cards through a lot of different channels or you don’t seem to fit in any particular bucket, this is your SAQ. Remember you have to meet all the requirements for the SAQ, if not your SAQ will be SAQ-D.

Step #5:

Identify your gaps. SAQ D has 288 individual requirements, so this can feel very daunting. The PCI Council’s Prioritized Approach can provide a good jumping off point if you’re looking to do all of this on your own. If you do decide as a company to take this project on internally, make sure you assign someone (or several someones!) who understand the business, are well connected and are well respected. You’ll need the project leader on this to feel confident engaging with technical and business staff and have the resourcefulness to know where to go to get answers.  

Step #6:

Put together your remediation roadmap. What were your major findings from the gap discovery/gap analysis phase? How do you plan to fix them? Almost every organisation will have policy and procedure work to do that can provide ‘quick wins’ on improving their posture versus PCI compliance at a relatively low price point. Big infrastructure undertakings will obviously take considerably more resources and planning. Where possible, try to understand what you have currently that can be leveraged more powerfully for compliance initiatives.

Step #7:

Fill in and submit your SAQ or RoC (depending on your level) and Attestation of Compliance. While everyone wants to be PCI Compliant, the simple fact of the matter is that almost every organisation does not start off that way! Don’t continually put off this step in the process because you’re waiting for your dream state of affairs to be willed into reality. If you’re not compliant, you’re not compliant. Submit your required documents and your plan – every acquiring bank I’ve ever worked with has been willing to work with their vendors who are proactive on PCI compliance. It’s better to take control before your bank comes to you about PCI because something bad has happened!

You can do as little or as much of this ‘on your own’ as you care to (except for Level 1 Merchants and Service Providers, who do need to engage a QSA!). It will require a lot of internal manpower if you have a complex organisation, complex payment processes, poor documentation, poor segmentation or some combination of all the above. You can bring in a PCI Consultant at pretty much any stage in this process. In my experience, bringing in a QSA at the scoping/de-scoping stage and at the gap analysis stage is good bang for buck compared to doing it all yourself, but again, it will really depend on your business and your specific situation.

If you do have any comments, concerns or clarifications, or if you need assistance on your PCI journey, feel free to reach out to the Shearwater QSA team or to me directly ( We’d love to hear your thoughts and take on any feedback you might have.