PCI Dream Team Holiday Event

On Wednesday, December 8, at 1PM ET/1800 UTC the PCI Dream Team will host its first ever holiday event as our “gift” to the PCI community.

To join us at our first holiday event, you can register here.

As with all of our sessions, please be prepared with your hardest PCI questions and concerns to stump the Dream Team. If you are unable to attend, you can always submit questions to pcidreamteam AT gmail DOT com and then review the recording of the session at TrustedSec.

So, hang the Mistletoe and let the Eggnog flow.

Happy holidays from the Dream Team (Ben, Coop, David and Jeff) and we look forward to “seeing” you at this holiday session.

Advertisement

There Will Be No PCI DSS v4

In a brief yet bold announcement, the PCI Security Standards Council today announced that the card brands have come to an impasse and cannot agree on key provisions of PCI DSS v4.

Council Communications Director, April Fools-Day, states in the Council’s Blog post that, “The card brands have tried and tried to work through their differences on key parts of the new version of the PCI DSS, but their differences have been unable to be resolved.  As a result, the Council has been informed that we will need to go back to pre-Council times when each card brand had their own security compliance program.”

An anonymous source from American Express stated that, “We fully expect to have our security program issued in a matter of days.  We were happy with where version 4 was headed, and we intend to publish that program with only minor revisions.”

A source from Visa USA who insisted on anonymity because they are not allowed to officially speak about the matter stated, “Version 4 as it existed was not an advancement.  Too many loopholes in the work program.  It wasn’t about to advance security of card data and was taking us back to the dark ages of information security.”

A Mastercard spokesperson stated, “What Visa said.”

Spokespeople for Discover and JCB had no comment on the news.

Dr. Brandon Williams, a known critic of the Council stated, “It was just a matter of time before this all imploded.  I have seen this coming for years.”

Dr. Anton Chuvakin, noted SIEM expert and author of many PCI DSS books, said, “Meh!”

The PCI Dream Team were stunned by the news.  However, after a moment to catch his breath, Art “Coop” Cooper said, “I suppose it was bound to happen at some point.  I just thought it would be decades out.”

It will be interesting to see the reaction to this news as people let it all sink in.  In the meantime, enjoy April the First.

Enjoy Vancouver

Due to a personal scheduling conflict, I will not be in Vancouver for the 2019 PCI Community Meeting. I will miss seeing, visiting and catching up with all of you.

I will be in Orlando for a LIVE version of the PCI Dream Team with Ben Rothke, David Mundhenk and Art “Coop” Cooper at the (ISC)2 Security Congress. We are scheduled for Wednesday, October 30, at 830AM in Northeast E2. If you would like to register for this conference, go here.

Enjoy this year’s CM and hopefully I will be at next year’s event.

Join The PCI Dream Team On Friday, October 26

The PCI Dream Team is getting back together again on Friday, October 26, at 5PM UTC/1PM ET to talk about “The Cloud” and PCI compliance as well as questions on PCI that you submit at pcidreamteam AT gmail DOT com or while we are speaking.

To register for this PCI Dream Team session, go to here.

We look forward to addressing your PCI compliance questions.

UPDATE: Thank you to everyone that joined us for this event.  Questions that were not answered will be answered here over time, so stay tuned.

One More Time

Let’s give it another try, shall we?

On Friday, June 15, at 1600 UTC, Noon ET the PCI Dream Team will try, once again, to answer your most difficult PCI questions. We hope to not encounter a technical glitch this time around.

Go to BrightTalk (https://www.brighttalk.com/webcast/288/325067) to register for the session.

We look forward to talking to you all.

UPDATE: BrightTalk originally gave me the WRONG link for registration, so all of you using the link you might have gotten via email was incorrect.  Please use the link from above to register.

UPDATE: BrightTalk has told us we will be on video as well this time. Wanted to provide fair warning. LOL!

Thank you to everyone that attended our last session.  Excellent questions even though my computer locked up and knocked me off the internet for around 10 minutes.

 

There Is No Such Thing As PCI “Magic”

It still amazes me the amount of effort some people and organizations expend in vain and silly attempts to “avoid” PCI compliance.  But an entire industry has popped up that claims to have just such “magical” solutions.

First and foremost is the fact that when your organization signed the merchant agreement to accept payment cards with your acquiring bank, you agreed to comply with the PCI DSS.  Unless your organization is willing to stop accepting payment cards, you are stuck with complying with the PCI DSS.

What you can do though is implement solutions that minimize your PCI scope and therefore simplify your PCI compliance efforts.  For those of you that need to cut to the chase, here are the ONLY solutions that minimize your PCI scope.

• If you operate a brick and mortar retail store, implement a point-to-point encryption (P2PE) validated solution or end-to-end encryption (E2EE) solution – both with tokenization. Do NOT enter primary account number (PAN) and sensitive authentication data (SAD) through anything other than the P2PE/E2EE terminal.  This will reduce your scope to those requirements in SAQ P2PE.
• If you conduct mail order and/or telephone order (MOTO), use a P2PE/E2EE solution with tokenization. Do NOT enter PAN and SAD through anything other than the P2PE/E2EE terminal.  This will reduce your scope to those requirements in SAQ P2PE.
• If you have an eCommerce Web site, use a redirect solution such as PayPal or an iFrame solution from a transaction processor such as those available from Vantiv, Elavon or TrustCommerce with tokenization. Implementing either of these solutions will reduce your scope to the requirements in SAQ A.
• If you need to do recurring transactions, do not store card information at all. Have your transaction processor send back reusable tokens instead when a customer puts a card on file.  Your processor can also likely provide you with a service to automatically update card expiration dates and card validation codes for a fee and save you from badgering customers to update their payment card accounts every three to four years.  How much this approach reduces your scope will depend on your organization’s payment channels such as eCommerce, MOTO, or brick and mortar retail.

There are no other ways to minimize PCI scope other than these.  For those that are interested, the absolute minimum PCI scope any organization can achieve are the requirements documented in SAQ A (i.e., a merchant with ONLY an eCommerce site using a redirect or iFrame).  There is nothing less.  Period.  Anyone that tells you otherwise does not know what they are talking about.

An important caveat on this discussion.  The more payment channels your organization uses, the less scope reduction you get.  For example, if your organization operates brick and mortar stores and also has an eCommerce site, you will have to comply with the requirements in both SAQ A AND SAQ P2PE if you follow my advice.  So keep that in mind as you evaluate and implement these solutions.

Yet time and again, I encounter organizations spending lots and lots of time, effort and money on all sorts of “magical” PCI compliant solutions sold by “snake oil” salespeople praying on the PCI uninitiated.  They promise all sorts of “magic” that will reduce PCI scope or, worst of all, remove your organization from PCI scope.  None of them deliver and people are deeply disappointed when they finally contact a QSA (or worse, their bank calls out the solution) and they find out that the money spent was all in vain and did not actually reduce or remove them from scope like they were promised.

Adding insult to injury is the fact that if the merchant had truly understood the solution and the PCI compliance process, it was all documented in the vendor’s contract as to how much scope reduction would actually be delivered (i.e., not a lot).

Stop spending so much time and money on Rube Goldberg solutions.  In the end, they are typically costly, complicated and likely do not reduce scope any better than the solutions outlined above.

The bottom line here is, if it sounds too good to be true, it likely is.

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.

Deadlines Coming Soon

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

PCI Requirement Changes Coming in 2018

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.

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.