Q4 2017 QSA Update

On December 7, 2017, the Council held their last QSA Quarterly Webinar for the year.  The following are the more notable tidbits offered up that should be passed around so that everyone has the information.

The Next Revisions Of The PCI DSS And PA-DSS

Emma Sutcliffe had a quick discussion of updates to the PCI DSS and PA-DSS.  There will be an update to both in 2018 once the June 30, 2018 deadline passes.  These will be minor releases (i.e., v3.3) and will change the coming best practices deadlines in 2018 and make them full requirements.  There is a great post on Optiv’s blog site that covers all of these.

During the Q&A portion of the meeting Emma did say that the Council expects a full release of both standards (i.e., v4.0) to come sometime in 2019.

This of course could all change if a breach occurs that is the result of something that the current standards do not cover.  Remember, the SSL/Early TLS issue resulted in v3.2 coming about.

Requirement Clarification

Service providers and their QSAs need to take note of this clarification.  A question that got answered during the Q&A portion of the Webinar was regarding the deadline for in January and how QSAs should deal with that as a new requirement.  What we were told was that as of February 1, 2018:

  • Service providers MUST have a plan, policies and procedures in place for conducting segmentation testing every six months.
  • Service providers MUST have at least one segmentation test conducted that is no more than six months old.

As of August 1, 2018 or six months after the date of the first segmentation test referenced above (whichever date is earlier):

  • Service providers MUST have had a second segmentation test conducted. If your PCI assessment date comes before your six-month segmentation testing date is due, FOR THIS ONE ASSESSMENT ONLY, you will need only the one segmentation test and the policies, and procedures.
  • Going forward service providers MUST conduct segmentation testing every six months, no excuses (and let me tell you, a CCW for this is going to be very ugly to construct).

What was not discussed in Emma’s answer, but I am sure applies, is that when the Council says six months apart, it is 180 days/six months plus or minus five days.  This is no different from quarterly testing where the Council has repeatedly told QSAs that quarterly is 90 days/three months plus or minus five days.  So those of you poor at date math (you know who you are) need to make sure that you follow this guidance as the Council will not give your QSA leeway which means that your QSA will give not give you leeway.

QSA Work Papers

This was an interesting discussion because coming out of the financial audit business, work papers were all part and parcel of the audit process.  As a result, work papers are forever engrained in my life.  But apparently, other QSAs are not necessarily as diligent.  Because this has become such a consistent finding in PCI SSC Assessment Quality Management (AQM) reviews, the Council felt that they needed to spend time on the subject.

The most obvious evidence that QSAs need to retain is the evidence that supports their analysis of compliance.  This includes things such as device configuration files, server configuration files, user lists, screenshots of security applications’ master consoles and log data.  But there is other evidence that is needed as well.

But also needed as evidence are interview and observation notes.  I cannot tell you how many assessments I have reviewed over the years that were missing interview and observation notes.  I have a work paper Word template for collecting meeting notes.  In the document heading I capture the client name, project name, date and the subject of the meeting.  In the body of the document are three sections.  The first section is where I capture the names and titles of the meeting attendees.  The second section are where I capture my meeting notes.  The third and final section is where I capture a list of any issues or follow up items I got from the meeting.

Here is how I take meeting notes.  I use an Excel spreadsheet of the PCI DSS requirements that allows me to filter by section and type such as interview, observation, documentation or sample.  I notate in my notes how I filtered that spreadsheet and then only capture issues or anything out of the ordinary in my meeting notes by requirement being discussed.  That way I am not always scribbling notes and can focus on asking questions.


As of this meeting, the Council is still holding the line on the June 30, 2018 deadline for stopping the use of SSL and Early TLS (TLS v1.0 and some configurations of v1.1).  If this date is going to change, the Council is being very quiet about it.  My recommendation is you need to do whatever you can to kill off SSL and Early TLS by that June date.

In a related discussion, Emma addressed a question regarding approval to use TLS v1.1.  She stated that people will have to look to the NIST document SP800-52 for how TLS v1.1 must be configured to be considered secure.


15 Responses to “Q4 2017 QSA Update”

  1. 1 Robert
    February 6, 2018 at 9:51 AM

    Yeah, sure, like those rigid segmentation control testing constraints demanded by the SSC are really going to be met by all Service Providers. I strongly doubt it. Try adhering to such scheduling in an Enterprise class production environment where one must follow change management procedures with notifications and approvals, avoid Yellow and Red no-change periods throughout the year, ensure SME availability in the required test window at all times and so on. Can’t be done IMO. Adhering to a 180 +/-5 day schedule might be achievable for SMB-class environments though.

  2. December 13, 2017 at 8:41 AM

    Great information as always, but I have a quick point of contention. Per PCI DSS FAQ 1447 titled “as of February 1, 2018, service providers must have a process in place to perform penetration tests of their segmentation controls at least every six months. It is not required that service providers have a penetration test of segmentation controls within the six months prior to February 1st, 2018.” This seems to disagree with your point that “Service providers MUST have at least one segmentation test conducted that is no more than six months old.” Also, per the recent “Q4 2017 PCI SSC All Assessor Webcast”, beginning around minute 10 of the webinar, Emma Sutcliff mentions that only a process must be in place to conduct the testing every six months as of the January 31 deadline. She goes on to say that it does not mean that the service provider must have completed a segmentation test within six months before this date, but instead that they must complete at least one within six months after the effective date. Thanks again and please let me know if I have just read this wrong or misunderstood what you were communicating. Love the site and the content you provide on a regular basis.

    • December 18, 2017 at 10:19 AM

      Blame the Council then for changing their minds. I’m just repeating the guidance they provided on their call. It was during the Q&A portion where she clarified how to handle the penetration testing.

  3. 5 amest01
    December 11, 2017 at 10:14 AM

    PCI DSS v3.1 was the early TLS blindside. V3.2 was the date change reprieve.

    Stephen Ames, CISA, CISSP
    Senior Director, Security Compliance

    Shift4 Corporation
    1491 Center Crossing Road
    Las Vegas, NV 89144-7047

    702.597.2480 ext. 46700
    fax 702.597.2499


    Shift4 Corporation Copyright and Confidentiality Statement

    The information contained in this electronic mail message may be proprietary to, confidential to, privileged information of, and/or the copyright of the Shift4 Corporation. It may be controlled in part or in full by contracted relationship and/or non-disclosure documentation. It is intended solely for the addressee(s). ACCESS BY ANY OTHER PARTY IS UNAUTHORIZED AND STRICTLY FORBIDDEN. The sender does not waive any related rights and obligations. If this message (or any attachments contained therein) has been sent to your organization in error, or have been otherwise intercepted, please do not review, distribute, or copy contents. Please reply to the sender that “A MESSAGE WAS RECEIVED IN ERROR” and then please delete the message including all related attachments from all (where applicable) email transfer agents, message stores, email gateways, email scanning systems, and/or logging systems.

  4. December 11, 2017 at 10:05 AM

    Note that NIST released a draft of SP 800-52 Rev. 2 last month. There is an abstract at https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft, along with a link to the draft document.

  5. December 11, 2017 at 9:46 AM

    That Optiv article is great. You should get that guy to help with this website. :p

  6. 9 Erik
    December 11, 2017 at 7:58 AM

    I’ve looked at the NIST SP800-52 document, but I have to admit I’m still not sure which TLS1.1 configurations are OK and which are not. I guess if it passes an up-to-date vulnerability scan, it’s OK though.


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 )

Facebook photo

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

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

December 2017

%d bloggers like this: