Archive for October, 2016

08
Oct
16

The Future Of PCI?

The 2016 North American Community Meeting was a celebration of the PCI SSC’s 10th anniversary.  And as with such anniversaries, the Council provided a look back and thoughts on the future.  During these looks into the future, I found some of their assertions questionable and they caused me to question the Council’s thought processes regarding the future of the Council and their standards.

The first instance was at Stephen Orfei’s keynote on the first day.  The General Manager of the PCI SSC proudly announced that the Council trains around 5,000 people annually and that there are current just over 2,000 QSAs and over 1,700 ISAs.  He then went on to explain that this is only the beginning and that more QSAs and ISAs would be needed.  But such a statement seems to be counter to where I think PCI is headed.

From the very beginning, the goal of the PCI standards has been to protect sensitive authentication data (SAD) and cardholder data (CHD) and the removal of it from processes that do not require it.  With most merchants moving to P2PE, E2EE and tokenization, the only scope at these merchants is going to be the card terminal or point of interaction (POI).  The only organizations that will have SAD/CHD remaining will be transaction processors and acquiring banks.  With that premise then why would there need to be growth in QSAs?  In my opinion, with merchant scope radically shrinking, the need to increase QSA and ISA counts is a pipe dream.

If there will be less of a need for QSAs, there will also likely be fewer QSACs.  Right now there are almost 370 QSACs in the world.  If all that will be left to actually assess are transaction processors, issuers and acquiring banks, then the number of QSACs will also have to shrink.  That means more competition for those transaction processors, issuers and acquiring banks until the QSAC numbers get to a more reasonable level based on market demand.

I could see the need for ISAs to potentially go up, but I would expect a lot of those people will just be QSAs that go in-house as the QSA numbers shrink.  With the scope of merchants shrinking so much, the need for ISAs is not going to be as large as I think the Council believes.  However, because of the silly Council rule that you cannot convert from a QSA to an ISA without going through the ISA training program, the Council will still have ISA training revenue regardless for the time being.

eCommerce will continue to be an ever larger part of merchants’ business.  But again, most merchants are moving to redirects and iFrames to reduce PCI scope.  While I fully expect the Council to adjust SAQ A to finally realistically address the risks of even redirects and iFrames that will likely not require any increase in ASVs who currently number 107.  Never mind the fact that the ASV business rapidly became a commodity long ago in its rush for every ASV to be a low cost provider.  As a result, there is very little margin left, if any at all, in ASV scanning.  Most ASVs are only in the business because they need to offer vulnerability scanning services to allow their clients to “one stop shop” their PCI compliance.  As a result, I really doubt that there will be any growth in the number of ASVs and I would not be surprised if the number of ASVs also drop over the next decade.

The next time I felt like the Council was going down the wrong path was when I attended the small merchant session.  What a waste of peoples’ time.  During that session, I leaned over to one of my colleagues who was there and I said, “Why is this taking so long?”

“What is your problem?” They asked.

“Why are they not just telling these small merchants to go to P2PE and tokenization?  Just get this done and done right.” I said very frustrated.

In my mind the small merchant session was 45 minutes too long.  This topic is one of those rare instances where it could be discussed in one of those TED Talk like 20 minute sessions.  Small merchants are looking for a quick answer and they have one.  P2PE and tokenization.  Period.  End of discussion.  Yet the group on stage continued to blather on and on and on.

There you have it.  I feel much better now that I have that off my chest.

04
Oct
16

The Great Multi-Factor Authentication Debate

The Council brings back the Assessor Session to this year’s Community Meeting and it takes only one question to get passions flowing.  The question was to get a clarification of a comment made by Ralph Poore, Director, Emerging Standards at the Council, about multi-factor authentication (MFA).

First a little background to get everyone up to speed remembering that the US National Institute of Standards and Technology (NIST) SP800-63B standard in question is still a draft and has not been finalized.  However, everyone expects this standard to be adopted largely unchanged and with only minor wording revisions that would not affect the overall recommendations in the standard.

What NIST stated about SMS was in section 5.1.3.2. Out-of-Band Verifiers of SP800-63B which states:

“Due to the risk that SMS messages or voice calls may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out-of-band verification is to be made using the public switched telephone network (PSTN), the verifier SHALL verify that the pre-registered telephone number being used is not associated with a VoIP (or other software-based) service. It then sends the SMS or voice message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change. OOB using the PSTN (SMS or voice) is deprecated, and may no longer be allowed in future releases of this guidance.”

NIST is only calling out that new implementations of SMS or voice MFA should consider the security implications of using SMS or voice for MFA.  But NIST has not totally invalidated any existing SMS and voice MFA solutions.  They just do not want any new implementations unless there is no choice because the process is already underway.  So while SMS or voice MFA can still be used in existing implementations, NIST is saying that future implementation of SMS and voice MFA are out of the question, have basically killed those solutions.

With that as our background, in a Community Meeting session, Ralph Poore stated that MFA to devices such as smartphones or back to the same device or browser (i.e., “soft” solutions) were not considered secure because of statements in the NIST Draft of SP800-63B.  I was attending a different session when Ralph made his statements, but I can tell you that my cell phone started buzzing with text messages from various people asking if we had all heard what we had heard.  But since there was no Q&A at that session, there was no way to clarify Ralph’s statements.

As a result, this issue was brought up in the Assessor Session to clarify those MFA comments.  Ralph stood and reiterated his remarks and that sent the room into an absolute tizzy.  It was pointed out that NIST had only invalidated SMS and voice for future two-factor authentication, not all soft token solutions such as RSA’s or Symantec’s application solutions.  However, Ralph continued to repeat his remarks saying that they had invalidated all soft solutions.  That brought the house down and people were loudly explaining that his comments were invalidating decades of recommendations for OOB MFA solutions.  Eventually the room calmed down and the Council agreed to review their position on such “soft” MFA solutions.

So that is where we are with this subject.  Time will tell if the Council revises its statements on MFA and comes into line with what NIST is saying on the subject.




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

October 2016
M T W T F S S
« Sep   Nov »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

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

Join 1,775 other followers