08
Dec
19

Are You A Level 2 Merchant? Beware The MasterCard Trap

I had a discussion with a prospective client and as things usually go you want to determine their merchant level.  As it turned out, they were confused about the differences between Level 3 and Level 4 and their bank was just as confused.  The merchant had a 2 to 1 advantage in Visa transactions (around 800K) over MasterCard and, in total, had more than one million transactions across all card brands.

When their bank couldn’t decide their merchant level, the bank referred them to Visa since the bank was affiliated with Visa.  Visa informed the merchant that they were considering them a Level 2 merchant because of the high volume of eCommerce transactions (80%+) and their total transaction count for all payment cards (around 1.3M).

With this information in hand I said, “Well, it looks like you’ll be doing a ROC.”

The CFO at the other end of the WebEx exclaimed, “Say what!  Why do we need to do a ROC?  The standard says we can do a self-assessment!”

Sadly, another merchant gets caught flatfooted by the card brand rules.  People think that the PCI DSS and other PCI standards are all they have to worry about for card payment compliance.  However, the card brands (i.e., Visa, MasterCard, American Express, Discover and JCB) also have their own security programs in addition to the PCI standards and those also need to be followed.  Think that is not the case?  That Merchant Agreement from the bank that someone in the merchant’s organization signed calls out that not only do PCI standards need to be followed but also the rules from the card brands the merchant has agreed to accept for payment (almost always Visa and MasterCard with one or more of the others) also need to be followed.

One of those “quirks” in the card brands’ programs that comes up is this one regarding Level 2 merchants and MasterCard.

The first thing everyone needs to remember is that if a merchant is at a certain merchant level for one card brand, they are at that merchant level for ALL the card brands.  The second thing to remember about merchant levels is that any of the card brands can set the merchant level for a merchant regardless of transaction volume.  I have had merchants end up as a Level 1 merchant with fewer than 30K transactions all because the dollar value per transaction was extremely high as with business to business (B2B) transactions.

With that information, a merchant now needs to go to the card brands’ Web sites for the brands you accept and review their rules.  If you go to the MasterCard Web site to the page titled ‘What merchants need to know about securing transactions’ and scroll down to the merchant level requirements for Level 2, you will see footnote 3 next to the requirement “Onsite Assessment at Merchant Discretion”.  That footnote states the following:

“Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

For an organization to get an employee trained as an ISA, you need an employee with backgrounds in compliance and technology.  Typically, this would be someone in the internal audit department that a lot of Level 2 organizations do not have or if they do have, the people do not have the time to take on PCI. Then there is the cost which is $3,100 USD plus travel expenses since most ISA training is not done locally unless you are lucky. And finally, there is the employee retention issue after such an investment.

In the end, most Level 2 organizations do not see the cost benefit of training one of their employees to be an ISA in order to do an SAQ.  As a result, that is why I get to my comment about Level 2 merchants doing a ROC.

Oh, and for the record, the PCI standards do not dictate which organizations can fill out a self-assessment questionnaire (SAQ) and which fill out a Report On Compliance (ROC).  The card brands dictate that based on merchant and service provider levels.  In this case, MasterCard has its own ideas in that regard when it came to Level 2 merchants.

08
Nov
19

Why The Roaring Silence About PCI DSS v4?

So, it has been over a week since v4 came out in draft for comments from QSAs, Participating Organizations and other stakeholders. Yet there has been nary a peep online about it even from The PCI Guru. I know a lot of people are pinging me and complaining because they want to know what is going on.

I would love to share my observations and opinions, but …

The Council made us all agree to a Non-Disclosure Agreement (NDA) that does not allow us to openly discuss the new version of the PCI DSS outside of our own organizations.  Because of this, you should not hear word one about the new version until the Council tells us it can be openly discussed.

It is not that we do not want to share. It is that we are not legally allowed to share.

So please be patient.

Update: From the November 2019 Assessor Newsletter.

Can I share information about PCI DSS v4.0 outside of my company?
We have received several inquiries about whether POs, QSAs, and ASVs are permitted to share information externally about PCI DSS v4.0, and if so, what information can be shared with other organizations. We encourage PCI SSC stakeholders to help raise awareness in the payments industry around the planned update to PCI DSS; however, access to RFC content and participation in RFCs is a benefit reserved for PCI SSC stakeholders. It is permissible for your organization to share information about PCI DSS v4.0 based on publicly available information from the Council, which is available in PCI SSC FAQs, blogs, and PCI SSC presentations from Community Meetings and other PCI SSC public events.

Note: The content of the RFC documents is strictly under NDA and cannot be shared, used, or quoted.

If you share any information about PCI DSS v4.0, as referenced above from publicly available materials from PCI SSC, you are asked to please reiterate the following in any material your organization presents or publishes:

  • Information provided is your company’s opinion and does not represent the position of the PCI Security Standards Council. For information from the PCI Security Standards Council on PCI DSS v4.0, individuals should visit the PCI SSC website.
  • Information about PCI DSS v4.0 is based on an early draft of the standard that will most likely change significantly over the several months.

Thank you for help in increasing awareness of PCI DSS and for your cooperation with these guidelines. It will help minimize confusion and ensure that clear, consistent, and accurate information is being communicated to the payments industry.”

29
Oct
19

PCI DSS v4 Draft Is Out

According to a PCI SSC Blog post, the Request For Comment (RFC) phase has started for the newest version of the PCI DSS.  The draft can be obtained at the PCI Portal (https://programs.pcissc.org/) which QSAs, Participating Organizations (PO) and ASVs have access.  The RFC phase began yesterday and continues though December 13, 2019.

I tried to find the documents in the Portal, but I am guessing that only the Key Contacts for organizations have access.

15
Oct
19

Why Recreate The Wheel?

David Mundhenk at The Herjavec Group and a member of the PCI Dream Team produced a great post about the top 3 PCI DSS concerns of 2019 that everyone should read. Since I am having a bit of a drought writing my own posts, I thought this would be a good one to share. Enjoy!

23
Aug
19

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.

07
Aug
19

The PCI Dream Team Is Back

On Thursday, August 15, at 1PM ET/5PM UTC the PCI Dream Team will be back online to answer your toughest PCI questions.  Sign up at https://www.brighttalk.com/webcast/288/361775 to attend.

If you would like to submit questions before the session or will be unable to attend the live event, send them to pcidreamteam AT gmail DOT com.

As always, we look forward to your questions and attendence.

Thank you to al that attended out latest session. We received a lot of great questions and those we did not get to we are saving those questions for out next session.

If you are going to the 2019 (ISC)2 Security Congress in Orlando (https://congress.isc2.org/events/-isc-security-congress-2019/event-summary-f1be4e92a1b54d92acdb1b8007fe91cf.aspx) you will be able to see the PCI Dream Team in person. We will be speaking on Wednesday, October 30, at 830AM in Northern E2. We hope to see you in person in Orlando.

23
Jul
19

Requirement 1.2.3 And Not Applicable

I had a question posed here a week ago that resulting in a discussion regarding whether or not PCI DSS requirement 1.2.3 can be marked as ‘Not Applicable’ or NA.  What prompted this discussion is a post from long ago where I discussed certain requirements that cannot be marked as NA.

The discussion revolved around this statement from page 4 of the PCI Report On Compliance (ROC) Reporting Template in a discussion about the difference between Not Applicable and Not Tested.

“Using the example of wireless and an organization that does not use wireless technology in any capacity, an assessor could select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, after the assessor confirms that there are no wireless technologies used in their CDE or that connect to their CDE via assessor testing. Once this has been confirmed, the organization may select “N/A” for those specific requirements, and the accompanying reporting must reflect the testing performed to confirm the not applicable status.”

I can tell you right now that the Council’s Assessor Quality Management (AQM) team has called out the fact that when they say “does not use wireless technology in any capacity” they mean absolutely NONE, NADA, ZIP.  I cannot tell you the number of discussions I and others have had in AQM reviews where they mark you down for missing this nuance.  At the end of the day, their rule is that the minute a QSA sees wireless whether it is corporate wireless, guest wireless, whatever, that means that 1.2.3 must NOT be marked NA.

In discussions with a variety of QSAs, we all remarked that we regularly see sections 3.7 and 3.8 mention wireless networks as well as it is documented in the network diagrams in section 4.1.  Yet, when you got down to 1.2.3 the QSA would mark it NA because the wireless did not connect to the CDE.  In today’s ultra-connected world, it is extremely rare (as in almost never) that wireless is NOT present and operated by any organization.  Even data centers have wireless installed in their facilities.

Even if that wireless is not in the CDE, the QSA is required to validate that the wireless has no direct access to the CDE.  That is exactly why 1.2.3.b specifically asks:

“Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.”

The QSA must reply either ‘Yes’ or ‘No’ to 1.2.3.b.  There is no NA option here.

If the answer to 1.2.3.b is ‘No’ (which is usually the case), the QSA is required to:

Describe how firewall and/or router configurations verified that firewalls deny all traffic from any wireless environment into the cardholder environment.”

The bottom line is – if there is ANY mention of wireless networking anywhere other than the requirements in 11.1, then 1.2.3 must NOT be marked as NA.

Hopefully we are all clear on how to address wireless networks now.




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 2019
M T W T F S S
« Nov    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

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

Join 2,147 other followers