Archive for the 'Uncategorized' Category

30
Mar
18

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.

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

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. Also discussed was the fact that the SSL/Early TLS deadline is still June 30, 2018.

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

May 2018
M T W T F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

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

Join 1,964 other followers

Advertisements