11
Dec
17

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 11.3.4.1 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 11.3.4.1 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.

SSL/Early TLS

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.

Advertisements
08
Dec
17

Deadlines Coming Soon

A good reminder that there are a number of deadlines coming in January 2018.

PCI Requirement Changes Coming in 2018

18
Nov
17

Chrome And Redirects

A bunch of us saw this Wired article the other day and began thinking, “I wonder if this will screw up any of our clients’ eCommerce sites?”

After all, a LOT of eCommerce sites went with redirects to reduce their PCI scope, so there is a big potential here for issues if Google does not get this right.  And if Chrome gets this capability, you know that Edge, Firefox, Safari and the like will not be too far behind in implementing their own version.

I know that Google is saying that it is for dealing with only “sketchy” sites.  But is a checkout redirect going to be treated as “sketchy” once Chrome gets this update?

Should prove interesting once this new version of Chrome hits the streets.  Probably ought to give your eCommerce developers a heads up on this and get them testing your site once this new release is out.

11
Nov
17

Can A QSA Rely On An ISA’s Assessment Work?

Questions have been asked at various Community Meetings over the years regarding reliance on internal and external audits, but none of us discussing this question could remember anyone asking the Council about ISAs.  The reason this issue repeatedly comes up is due to organizational audit fatigue.

With standards such as PCI, NIST, ISO and the like, some organizations can be under constant and never-ending audits.  To add to this audit onslaught, the personnel involved are, in a lot of cases, covering the same topics over and over and over.  For the people involved, these endless audits become very annoying as these people are interrogated over the same topics time and again.

For the record, when the Council has been asked about internal and external auditor results, the answer has always been an emphatic “No”.  That answer has, of course, been met with groans and complaints from the audiences that the Council is arrogant and unrealistic in how they approach assessments.  While some of these complaints are on point for policies, access controls and physical controls, there are some PCI requirements such as those in sections 1, 2, 10 and 11 that are unique in the level of detail explored and are not covered in that same level of detail in other standards’ work programs.  Both the Council and the people making complaints have their points.

So, we come back to the original question about ISAs.  In theory, ISAs are provided the same training as a QSA by the PCI SSC.  The only difference between a QSA and an ISA is that an ISA is employed by the organization being assessed.  As a result, you would assume that all things being equal, a QSA should be able to rely on an ISA’s assessment work after a review of that work.

Nope!

According to the response we got back from the Council, a QSA must first ask the entity receiving the assessment if they can rely on an ISA’s assessment work.

QSAs are told not to question the work of other QSAs.  But we need to ask permission to trust the work of an ISA?  You are required to trust one, but cannot trust the other?  What kind of nonsense is this?

With answers like this, you start to wonder what the purpose of the PCI SSC is in the scheme of PCI.

And we all though the discussion about “Not Tested” was ridiculous.

26
Oct
17

Interesting Tidbits Out Of The PCI European Community Meeting Assessors Session

Usually the European Community Meeting uneventfully passes because everyone reads the slide decks, Twitter feeds and feedback from the North American CM.  However, with the cancellation of this year’s North American CM due to Hurricane Irma, that gave the EU CM the spotlight.

While we will all get the slide decks (and supposedly videos) via the portal, here are some interesting tidbits from the Assessors Session in Barcelona thanks to Yves Desharnais who attended the EU CM.

  • Emma Sutcliffe confirmed that the next major revision, i.e., v4.0, of the PCI DSS and PA-DSS are slated for a 2019 release (obviously barring any dramatic change in threats/attacks).
  • Emma also confirmed that there could be a “point” release, i.e., v3.3, of the PCI DSS and PA-DSS in 2018 to clean up errors and the like such as was with 3.1 and 3.2. Maybe while they are at it they can fix the ROC Reporting Template so that it does not cause Word to do strange things.
  • Jeremy King stated that the situation with SSL and Early TLS may be revisited before June 30, 2018. Apparently, the feedback from POI service providers and others are causing them to revisit that situation.

Now we are all in the know.

UPDATE – 12/07/2017 – According to the Quarterly QSA Webinar today, the next release of the PCI DSS and PA-DSS are expected in 2019.

29
Sep
17

What Are You Really Interested In?

As a QSA, we hear this comment all of the time.

“PCI is all about compliance, not security.”

The implication being that the person talking is interested in actually securing their environment not just being PCI compliant.

Yet as the conversation goes on, we get into esoteric discussions regarding scope and how scope can be minimized.  Not necessarily a bad thing, but as these discussions continue, an underlying theme becomes apparent.

This conversation eventually leads to the QSA asking, “What are your drivers that are making you so concerned about minimizing scope?”

The inevitable answer is, “Because, we want to minimize the cost of and/or difficulty in implementing (in no particular order) information security, increasing information security personnel, how many devices we vulnerability scan and penetration test, critical file management tools, anti-virus licenses, devices needing log aggregation and analysis, [insert your security tool/product/device/appliance/widget here].”

It is at that point it becomes painfully obvious that the organization is not at all interested in security.  In fact, they do not give a damn about security.  Their only interest is in checking off the PCI compliance box and moving on to the next annoying compliance checkbox on their list.

I am sure a lot of you are questioning, “How can you be saying this?”

Because, if the organization were truly interested in security, all of the things they mention in their minimization discussion would already be installed in their production environment, if not QA and test environments.  That is right.  They would already be installed and not just on the PCI in-scope stuff.  It would already be installed everywhere in those environments.

Why?

Because all of these security tools and methods are part and parcel of a basic information security program that follows information security “best practices”.  They are not special to PCI, they are required for any successful information security program such as HIPAA, FFIEC, FISMA, HITRUST, etc.

People seem to think that the PCI SSC and the card brands came up with the PCI DSS requirements by arbitrarily pulling the requirements out of thin air.  In fact, I have had people insinuate that the PCI standards are just there for the banks to be mean to merchants and extract more money from them.

But in actuality, the PCI standards come from a lot of recognized sources including the US National Institute of Standards and Technology (NIST) security standards and guidance, US Department of Defense (DoD) security standards and guidance, as well as “lessons learned” from the card brands’ cardholder data breach forensic examinations and working with information security professionals sharing their knowledge of what are the minimum, basic “best practices” required to secure data.

But the key words here are ‘minimum’ and ‘basic’.

Because guess what?  If you want true security (remember that thing you supposedly wanted when we started), then you have to go beyond the PCI DSS requirements.  Hear that people?  If you want true security, your organization must go BEYOND the PCI DSS requirements.  Organizations are complaining about doing the basics.  Imagine what their complaints would be like if they had to do true security?  They would be throwing a tantrum that would be easily heard around the world.

Want actual proof that organizations are not doing the basics?

Read the Verizon Data Breach Investigation Report (DBIR) or any of the dozens of data breach reports issued annually by forensic analysis firms.  They all read the same; year after year after nauseating year.  Organizations cannot consistently execute even the basic security requirements specified in any security standard.  Even more disheartening is the fact that it is the same vulnerabilities and mistakes that are the root cause of the vast majority of breaches.

QSAs still get complaints from organizations about the PCI DSS being too difficult and costly to implement and maintain.  Yet these same organizations have the gall to say that PCI is NOT about security.

So, before you go and tell your QSA that PCI is all about compliance, think long and hard about that remark and why you are saying it.  Odds are you are saying it to look good, make a good impression with your QSA, show them that you are a true security professional and that your organization wants to be secure.

Think again.  The truth will eventually come out.  One way or another.

08
Sep
17

The Party Is Off

Here is the official announcement from the PCI SSC that this year’s North American Community Meeting in Orlando has been cancelled due to Hurricane Irma.

https://www.pcisecuritystandards.org/nacm2017_schedule_irma

See you all next year.




Announcements

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

December 2017
M T W T F S S
« Nov    
 123
45678910
11121314151617
18192021222324
25262728293031

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

Join 1,904 other followers