Posts Tagged ‘PA-DSS


Remote PCI Assessment Guidance Issued

At the end of September 2021, the PCI Council released a Guidelines and Procedures document on conducting Remote Assessments for PCI and card brand assessments.  Most of this document is a rehash of previous Council statements and guidance.  However, there is one new element in this document that all QSAs will need to read and comply with and that is the requirement of documenting a feasibility analysis to justify conducting a remote assessment.

Some of the examples the Council gives as valid reasons that an on-site assessment may not be feasible includes:

  • Restrictions on the ability to travel or meet in person due to health and safety concerns or government advisories.  We are all familiar with the COVID-19 pandemic and its impact on travel, particularly international travel.  However, I encountered this a while back due to a volcanic eruption in Iceland that cancelled my trip to Europe.  Since we had no way of knowing how long the eruption would cause travel disruptions and we were on a tight timeline, we conducted video conferences rather than travel.
  • Geographic locations that are physically inaccessible or difficult to reach.  I personally ran into this situation one several years ago when a data center in Europe that was supposed to be decommissioned before the next assessment remained operational.  The company I worked for had shut down their EU operations and there was no way to justify 16 hours of flight time for a two-hour data center walk through.  We held meetings with the data center operator via video conference and did a virtual walk through.
  • Testing required at a location is limited to documentation and interviews and no observations of processes, systems or physical environment apply.
  • The entity operates a virtual environment without physical premises or facilities.  This has become more and more common with entities that operate in The Cloud.  Why rent expensive office space when there is not need for it?  This situation only got more prevalent with the pandemic and will likely only increase in the future.

As the Council states in their guidance,

“For many assessments, a combination of onsite and remote testing may provide a suitable balance, as it allows for increased efficiencies in the assessment process while enabling an appropriate level of assurance to be achieved in the assessment result.  For example, documentation reviews can often be performed remotely without significant loss of assurance, whereas observations of processes and environmental characteristics will generally require an onsite review.”

Regardless of whether the assessment fits into one of the bullets above, the Council wants QSAs to formally document their analyses of why the onsite assessment cannot be performed and the risks that may present to meeting the assessment objectives.  This analysis needs to be completed prior to starting any testing and is supposed to be a joint effort between the assessor and the client.

Topics that the Council recommends be addressed include, but are not limited to:

  • Confidentiality, security, and data protection requirements.
  • Availability and effectiveness of the remote assessment technologies.
  • Effects on entity’s personnel.
  • Effects on operation support.
  • Assessment scope and completeness.
  • Quality and reliability of digital evidence.

The Council further states:

“During the analysis, the entity and assessor should identify any challenges and potential risks associated with the remote testing and determine whether it is feasible for testing to be thoroughly completed to produce a high level of confidence in the assessment results.

The results of the feasibility analysis—including the risks and challenges associated with use of the remote testing methods, and any mitigating controls for overcoming the risks and challenges—should be documented and agreed upon by both the entity and assessor. A copy of the feasibility analysis results should be included with the applicable ROC/ROV. Entities and assessors may be required to produce the analysis upon request by the PCI SSC or applicable compliance-accepting entity.

The key points from that statement above is that: (1) the feasibility analysis needs to be submitted with the ROC/ROV and, (2) if requested by the PCI SSC or compliance accepting entity (i.e., Brand or bank), the QSA is required to produce the analysis.  As a result, this is a non-optional exercise.

The feasibility analyses must document that:

  • The assessment is feasible to be fully completed at this time using onsite methods, remote methods, or a combination of onsite and remote methods.
  • The assessment is only feasible to be partially completed at this time.
  • The assessment is not feasible currently.

According to the guidance, it is only those assessments that are completely feasible that can be conducted.

The Council includes a very important note regarding the analyses.

“The feasibility analysis determines whether the use of remote testing methods is feasible for a particular assessment.  Determining that a remote testing method is feasible does not guarantee that use of the testing method will produce the level of assurance needed for the assessor to reach a finding; this will depend on how the remote testing method is implemented and used, whether the testing can be completed for all applicable components and areas, and whether sufficient evidence is provided for the assessor to make a determination.  Assessors and entities should continue to monitor and evaluate the effectiveness of the remote testing methods throughout the assessment to confirm whether the testing methods are performing as intended and whether additional testing may be needed.”

This concept of “assurance” appears to all be in the eye of the beholder.  Meaning, if the Council, Brands or Banks determine, in their opinion, that the remote methods are not providing appropriate levels of assurance, the ROC/ROV can be rejected.  Not that a lot of banks are going to reject ROCs/ROVs on this, but I can see the Council’s AQM reviews and Card Brands rejecting ROCs/ROVs on analyses that they deem flawed or incomplete.  The AQM process is the most concerning because a QSAC could end up in remediation due to a failure to appropriately document the remote assessment feasibility.

As with most edicts issued by the Council, they should have produced a form for this feasibility analysis so that everyone understands what is required from these feasibility analyses.  Can the feasibility analysis be documented in section 1.2 of the reporting template or is a separate document required?  I would recommend this for the obvious remote assessments of COVID and everything in The Cloud.  I would recommend a separate document for feasibility analyses that are longer in discussion.

Sadly, I foresee a lot of confusion and heartache in the QSAC community as we move through this new requirement.  That is because I see a lot of assessments that are blocked due to COVID travel restrictions or the assessed entity having no physical offices being rejected for “flawed” feasibility analyses when it should just be allowed with no further documentation or discussion.

It will take time to see how this shakes out.

UPDATE 11/29/2021 – I received a comment on this post (see below) and the confusion is beginning. A service provider has had one of their customers request the documentation regarding what is provided in Appendix A of the remote assessment guidance document as well as the remote assessment feasibility study. Since these are ROC documents, there is no requirement from the Council that requires any organization to turn over their ROC to any third party other than their acquiring bank or the card brands. The AOC is the communication document to third parties. If an organization wishes to turn over Appendix A from the guidance, that is the organization’s decision, but it is NOT mandatory nor it is required by the Council.


Council Surveys QSAs On SSL

This message popped into my inbox late yesterday.


The survey in question contains the following questions.


All of my clients have gotten rid of SSL on their public facing Web sites.

The dilemma we have is that while SSL is dead, it is baked into so many products and appliances.  My clients are therefore stuck with appliances and software products that have SSL hard coded into them.  As a result, they will be dependent on their vendors to convert to TLS.

That said, what is the risk of using SSL internally?  Not a good practice, but truthfully, what is the risk?

In my opinion, using SSL internally for the next 12 to 24 months would not be the end of the world as long as it does not become a significant attack vector.

It will be interesting to hear the results of this survey.


SSL Is Officially Declared Dead

On January 30, 2015, QSAs received the latest edition of the Council’s Assessor Newsletter.  Buried in that edition was the following statement.

Notice: PCI DSS and PA-DSS v3.1 Revisions Coming

In order to address a few minor updates and clarifications and one impacting change, there will be a revision for PCI DSS and PA-DSS v3.0 in the very near future. The impacting change is related to several vulnerabilities in the SSL protocol. Because of this, no version of SSL meets PCI SSC’s definition of “strong cryptography,” and updates to the standards are needed to address this issue. (Highlighting emphasis added by the PCI Guru)

We are working with industry stakeholders to determine the impact and the best way to address the issue. While we do not have the final publication date, our goal is to keep you apprised of the progress and to provide you with advanced notification for these pending changes. We are also preparing several FAQs that will accompany release of the revised standards.

Should you have any questions, please contact your Program Manager.”

Because the announcement was titled about the coming v3.1 revisions to the PCI DSS and PA-DSS standards, I am sure a lot of QSAs missed this pronouncement.

Not that this should be a surprise to any QSA as the POODLE vulnerability effectively killed SSL.  The Council has now officially announced that SSL is no longer deemed to be strong cryptography.

Therefore, those of you still using SSL to secure transmissions containing cardholder data (CHD) need to stop that practice as soon as possible and convert to TLS or IPSec.

UPDATE: On February 13, 2015, the PCI SSC issued an update to their original announcement in the Assessor Newsletter.


Keeping It Simple – Part 2

In Part 1, the key to keeping things as simple as possible is to avoid any storage of cardholder data.  Period.  End of discussion.

I also covered mobile payments because more and more small merchants go to those solutions because of the cheap interchange fees on transactions.  However, few small merchants truly understand the risks that these solutions present because they are offered by seemingly trustworthy providers.

So what else can you do to keep things simple?


When consultants typically mention outsourcing, huge amounts of money typically float past people’s eyes.  However, PayPal is outsourcing and its fees are not too bad.  There are a number of similar services for eCommerce out there for conducting payments.  There used to be concerns about abandoned shopping carts because of a separate Window pop up, but as online shoppers have gotten used to PayPal like services, that has diminished.

Your bank may also have a partnership with one or more payment vendors, so it is worth it to talk to them first to find out what options they may have to offer.  If they do partner with a payment solution, a lot of times they can offer reduced fees/expenses and other incentives to use their partner(s).

The key thing to understand is that even when you invoke PayPal or similar services from your Web site, you still have a responsibility to ensure the security of your Web site.  This is because your Web site is the system that directs your customer to the payment service you have chosen.  If an attacker changes that redirect to “The Guru’s Payment Process”, that is not PayPal’s problem, that is your problem.  This was clarified in the PCI SSC’s Information Supplement on eCommerce back in January 2013 when the Council declared that even Web sites that redirected to a payment service still were in scope, albeit a very reduced scope.  The ramifications of this supplement have been discussed repeatedly with QSAs since then, but in my experience that message is still not being consistently presented to QSAs’ customers.

No Choice But To Store Cardholder Data

So you have found a solution that does exactly what your business needs, but it stores cardholder data (CHD).  The first question you should ask the vendor is, “How does your solution secure the stored cardholder data?”

For vendors that use data encryption, the answer to this question should be either triple DES (3DES) 168-bit or advanced encryption standard (AES) 128-, 192- or 256-bit encryption.  DES and 3DES 56- and 112-bit are no longer considered secure, so any vendor using those is not meeting the PCI encryption requirements.  Anything else and you should consult with a QSA as to whether or not the encryption algorithm is acceptable.

For vendors using encryption, the next question you should ask them is, “How does your solution perform key management?”  Preferably, someone other than someone in your organization manages the encryption keys such as the vendor.  However, I have seen some solutions where the key management is done by the merchant through a sophisticated key generation solution in the application so that the merchant never actually knows or has access to the encryption key(s).  The questions you need answered are all in requirements 3.5 and 3.6 of the PCI DSS.  If the vendor cannot address these requirements, then you need to find a new solution vendor that can provide answers.

For vendors that use one-way hashing, the preferred algorithms used should be SHA-2 or SHA-3 with a salt value.  MD5 and SHA-0 have known security issues that make them no longer secure.  SHA-1 has a potential security issue that could cause data to also be insecure, but a lot of software vendors still use SHA-1 with a salt value.  If you are going to use a solution that relies on SHA-1, the vendor should have additional controls in place to monitor access to the data and alert on any access where the data is being accessed in bulk.  If not, find another vendor.


Do not give up hope if your preferred solution stores cardholder data (CHD).  You may be able to use a processor that tokenizes the PAN.  Once tokenized, the PAN is no longer considered CHD, so the solution would not being storing CHD.

Proper tokenization is a form of encryption or hashing in that the token does not have any true one-to-one relationship with the PAN it replaces.  However, this is a fact you need to confirm with the transaction processor to ensure that their tokenization process is secure.  If they are not representing their token as secure, you need to move on to another processor.

Tokenization can occur at the swipe/dip of the card at the point of interaction (POI) or as the byproduct of the successful completion of a transaction (the most common occurrence).

Tokens can also be generated for eWallet situations where you want to encourage customers to come back and shop at your eCommerce site and store their cardholder information for ease of subsequent transactions.  In these instances, the processor generating the token also stores the CHD and then translates the token to that stored CHD when your system submits it and then sends the CHD for approval for payment.

This is how ExxonMobil Speedpass and open road toll collection systems work.  The RFID device is the token and the payment system recognizes the serial number of the RFID device and translates that to the customer’s stored CHD for payment processing.

There are more than enough ideas presented in these two posts to vastly simplify any merchant’s PCI compliance exposure.  If these solutions will not solve your issues, then you are either making your business too complex or your business model truly needs some expert advice to address your compliance challenges.


Pre-Authorization Data

After a number of interactions with a variety of people over the last few weeks, it has become obvious that the concept of pre-authorization data is not clear to a lot of people.  And just because it is pre-authorization data does not mean that you are not required to protect it.  The Council has made it very clear that it is to be protected with the same rigor as post-authorization data.

Pre-authorization is defined as that time when an organization has a customer’s sensitive authentication data (SAD) but has not yet processed it for payment.  For most merchants, the time between collecting the SAD and processing it is measured in seconds.  For card present transactions, the SAD can be track or chip data.  For card not present transactions, it typically includes the cardholder name, primary account number (PAN), expiration date and CVV2/CVC2/CID2.

Here are some situations where that does not always happen that quickly.

Phone, facsimile and mail orders can extend the amount of time between receipt of the SAD and processing by seconds, minutes or even hours.  On the bizarre side of things, I encountered at one client people sending their physical cards in the mail for processing of their mail order.

At the fuel pump when a customer swipes their card, the system that manages the payment process will pre-authorize the purchase and then store the SAD until the customer finishes pumping fuel and hangs up the hose to complete the transaction.  That could be five to 10 minutes depending on fuel tank size.

In some industries the time of pre-authorization can be weeks, months and in some cases even a year or more.  Where this typically occurs is in the airline and hospitality industries.

When a customer makes an airline reservation, the airline will likely pre-authorize your airfare but may not actually charge your card until 7/14/60/90 days before you check in or even until you check in.  This can result in your SAD being stored for weeks or even months.

In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation.  When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out.  I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries.  New versions of hospitality management systems encrypt pre-authorization data, however older systems did not and the security of the pre-authorization data may not be a rigorous as it should.

eWallet applications are another great example of pre-authorization data.  eWallets are just an electronic version of a consumer’s physical wallet.  eWallets can be applications on a smartphone/tablet or a specialized device such as Coin.  eWallets are not regulated by the Council or the card brands and never will be just as traditional wallets are not regulated.  That said, developers of eWallet applications should follow the PA-DSS for developing secure eWallet applications.

The most confusion over pre-authorization data typically occurs over SAD that an organization receives via email.  A lot of QSAs get their “undies in a bunch” over this and point to requirement 4.2 as the reason why this is unacceptable.  Requirement 4.2 states:

 “Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”

The operative word in 4.2 is “send”.  Requirement 4.2 says nothing about receiving PANs by these methods and the reason is that it is pre-authorization data.  That does not mean that the Council recommends receiving PANs via email, IM or similar methods.  It is only recognition of what goes on in the real world.  There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it.  But even before you start the argument, you need to acknowledge that this data is pre-authorization data because a transaction has yet to be processed.

To keep your email system out of scope, the Council has told QSAs to make sure that organizations have a process to remove the SAD as soon as possible from the system(s) in question.  That typically involves the printing of the message, deleting the message from the system and then securely destroying the printed message once the transaction is processed.  This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable and consistently executed.

Web sites that store customers’ SAD for future purchases are also dealing in pre-authorization data.  Merchants providing such a service should contractually acknowledge their responsibility to protect that data with the same rigor as post-authorization data and that the stored data is only for use for purchases by the customer on the merchant’s Web site.

My final example of pre-authorization data is when an organization’s travel department stores employees’ card data for company travel reservations.  The systems used by these departments typically store the cardholder name, PAN, expiration date and the CVV2/CVC2/CID2.  When the PCI DSS originally was published, the card brands instructed QSAs that these sorts of systems were not in scope for an organization’s Report On Compliance (ROC).  However, as time has passed, some of the card brands now want those systems included in the ROC, so organizations need to contact the card brands to determine if their ROC should include such systems.  These systems can be interesting in how little protection they can provide for SAD, so regardless of whether they are included in the organization’s assessment, the organization should review the security of the application against the PCI DSS and mitigate any gaps.  As with the aforementioned Web sites that store pre-authorization data, an organization storing SAD for their employees should legally acknowledge their responsibility to protect that data as well as document how it may be used.

The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s magnetic stripe or chip.  Merchants can store pre-authorization data until a payment transaction is processed.  If they do store the pre-authorization data, they are obligated under the PCI DSS to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc.

Hopefully we are now all on the same page.


PCI DSS v3 and PA-DSS v3 – Wait For It

There are all sorts of QSAs and other experts who are weighing in on the new versions of the PCI DSS and PA-DSS that were released around the first part of November.  In my very humble opinion, all of this discussion is speculation, at best, because the PCI SSC has not released the final pieces of the standards puzzles.  Those final pieces are the respective Reporting Templates for those standards.  Without those templates, QSAs and PA-QSAs have no idea of what the true testing and reporting requirements they will be held.  As a result, the impact of the changes to the standards will not truly be known until QSAs and PA-QSAs have the templates and can review the new testing and evidence requirements.  While I am not expecting the sort of major changes that resulted when the version 2 Report Instructions were released, there still could be some surprises that could impact the amount of work and evidence collected.  The PCI SSC has not committed officially to a release date for the Reporting Templates, but the rumor is that they will be available around the first part of March 2014.

There are some comments that can be made and I will be covering some of those points on a Webinar sponsored by Tripwire on Monday, December 16, at 7PM UTC / 1PM CST.  If you care to attend, you can register for the session here.  “See” you there.


Hot Off The Press

The PCI SSC released the final versions of the PCI DSS v3 and PA-DSS v3 this morning.  You can get your copies here as long as you sign their agreement.  The Change Summary documents for both are also finalized and available in the library.  Enjoy!


Thoughts From The 2013 PCI Community Meeting

I got lucky that my new employer allowed me to go to this year’s PCI Community Meeting held in Las Vegas.  It is always nice to hear things first hand versus getting the slide decks, asking questions of the people that attended about certain points in the slide decks and finding out that the people attending did not think a question was needed or they cannot remember what was said.

Probably the biggest revelation out of this year’s Community Meeting was from the Qualified Security Assessor/Approved Scanning Vendor (QSA/ASV) session the day before the Community Meeting started.  It seems that the Council has finally addressed with v3 the message a lot of Qualified Security Assessor Companies (QSACs) have been putting forth regarding the time it takes to write a Report On Compliance (ROC).  Those of us complaining have argued for years that the ROC writing process occupies too much of a QSA’s time (anywhere from 50% to 70% of a project).  As a result, under today’s Reporting Instructions, QSAs tend to worry more about what to write than making sure their client is actually compliant and advising that client how to better maintain compliance.

The ROC will now have an overall ranking for the entire requirement that is a check box that indicates whether the requirement is ‘In Place’, ‘In Place with Compensating Control’, ‘Not Applicable’, ‘Not In Place’ or ‘Not Tested’.  Then under the requirement, will be the tests for the requirement.  It is with each test where the QSA will provide a list of documents reviewed, a list of people interviewed, observations made and sampling selected.  QSAs will no longer have to write meaningless but Quality Assurance approved diatribes regarding a test.  All that will be needed is a list of documents, a list of persons interview, a list of observations made and a list of samples taken.

Now before some of you go nuts about the check box, the Council has not adopted a check box assessment approach.  QSAs are still required to conduct their assessments in a process similar to what is conducted today for a PCI DSS v2 assessment.  What the Council is doing is simplifying the reporting generation and review processes.  The Council finally acknowledged the fact that, other than QSAs and their QA reviewers, practically no one was reading the 300+ page tomes that were being produced – even the acquiring banks.  What they are doing is making the ROC easier to review and read as well as lessening the writing requirements so that QSACs can more readily adopt automated systems to facilitate the conducting of assessments and generating the ROC.  The idea is that this will then allow QSAs to focus on assisting their clients with PCI compliance related activities and fold into the ‘Business As Usual’ approach that is being rolled out with v3.

The most intriguing category is ‘Not Tested’.  The Council added this category for those situations where a QSA did not test the control.  This most often occurs when a QSA is relying on a Service Provider’s Attestation Of Compliance (AOC) for that control such as with firewall configuration management, network security monitoring, custom application software development or other services.  The Council also indicated that Service Provider AOCs may also be getting modified so that QSAs and others relying on them can determine what PCI requirements the Service Provider’s AOCs actually tested.

Now the bad news about this great advancement forward.  The Council has no idea when the final version of the Reporting Template will be available.  Since v3 of the PCI DSS will not be finalized until November, they do not yet have a timeline on how quickly after the release of v3 that the Reporting Instructions will be released.  As a result, QSACs will likely not be rolling out PCI DSS v3 assessments until the Reporting Template is released.  One reason will be because of the major changes involved in v3 and, probably the larger reason, because none of the QSACs want to be put in remediation by the Council for creating ROCs that do not meet the Council’s Quality Assurance requirements.

On the new requirements front, there was a lot of discussion within the QSA ranks on requirement 6.5.6 regarding protection and secure deletion of device memory when cardholder data (CHD) or sensitive authentication data (SAD) were stored in memory during a transaction.  As the Council has defined it in the QSA/ASV session, the QSA will interview developers to discuss what they are doing to secure memory and properly delete CHD/SAD.  QSAs will also observe that developers are in fact coding for this condition.  While this requirement will bring the memory scraping threat to light, most of the QSAs I talked with agreed that the proposed testing is not going to actually have any significant impact on the memory scraping threat of vSkimmer, BlackPOS and the like.  And for PA-DSS certified software (v3 of the PA-DSS addresses this threat as well), the horse has already left the barn for those applications.  The bottom line is that memory scraping attacks will continue to proliferate until the software vendors address the problem.

I asked a question about PCI DSS v3 requirement 1.3.7 and how it would impact merchants that have their card terminals connected to the Internet for transaction processing.  Requirement 1.3.7 states:

“Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

System components that store cardholder data must not be located in a DMZ or be accessible from the Internet or other untrusted networks”

My confusion was over how all of the merchants I encounter with card terminals that directly connect to the Internet would be able to comply with 1.3.7.  After all, in most instances, these card terminals store SAD in memory until the transaction is completed.  The Council representatives admitted that the wording in 1.3.7 was a problem and that they would be looking at rewording it because of this and other similar issues that create a conflict.

Finally, the other big discussion topic was ‘Business As Usual’ or BAU.  For v3 of the PCI DSS, the Council wants organizations to integrate the requirements of the PCI DSS into their day-to-day processes and then periodically test that the integration has occurred and confirm that the integrated controls are working.  At the QSA/ASV session BAU generated a number of questions as to what QSAs were expected to test to assess BAU.  The Council admitted that BAU is only a suggested ‘best practice’, not a requirement, which placated a lot of the audience.  But if you think about it, if an organization desires to be PCI compliance, BAU should already be occurring in the organization.  This is obviously a reminder to organizations that do not get security to provide an incentive for further integrating security practices into their day-to-day processes.

As usual, there was a lot of information sharing between QSAs, ASVs, POs, card brands and the Council at this year’s Community Meeting.  The Council members seemed more relaxed than at the roll out of v2 three years ago.  Hopefully the roll out of v3 will go much less eventfully than v2.


Mobile Payments Update

This past week, Bob Russo, General Manager of the PCI SSC, held Webcasts to discuss the changes coming to version 3 of the PCI DSS and PA-DSS.  For the most part, these Webcasts were nothing special.  Just a scripted regurgitation of what was published in the Version 3.0 Change Highlights document release earlier this month.

However, at around 35 minutes into the Webcast I attended, things got very interesting and an actual useful piece of information was shared.  For it was at that point that Mr. Russo launched into a discussion about mobile payments and the use of consumer devices such as smartphones and tablets for the processing of card transactions.  Mr. Russo stated:

“The fact is that many consumer mobile devices simply cannot provide the level of security needed to adequately protect payment card data.  In other words, they cannot create a trusted environment equivalent to the PCI DSS compliant cardholder data environment.”

Whoa!  Now there is a piece of information I was not expecting.  I looked at the slide and these are the bullets on the slide.

  • PCI Standards focus on merchant acceptance
  • Mobile payment acceptance still evolving
  • Understand risk and use PCI SSC resources
  • PCI SSC is working with industry

Mr. Russo went on to say:

“We encourage merchants to understand the risk of using mobile, work with their acquirer and make their own decisions about mobile and whether they are willing to accept that risk.”

“We’re working with others in the industry including: standards bodies, vendors, banks and processors.  But we are unwilling to lower the bar for security by writing a standard that current mobile devices could meet.  If we wrote a secure standard for mobile now, no consumer devices would be able to meet it.”

The bottom line in all of this is that all of you merchants using iPads, iPhones, Android phones and tablets and similar devices are using them at your own risk.  They are not PCI compliant.  Not only that, you should have cleared that decision with your acquiring bank so that they also accepted the risk that you were using mobile devices to accept payments.

Mr. Russo referred Webcast attendees to reference the PCI SSC Information Supplement ‘Accepting Mobile Payments with a Smartphone or Tablet’ for additional information regarding the use of such devices.

Mr. Russo also reminded everyone that mobile payments from the consumer side are not within the purview of the PCI SSC and the PCI standards.  So wallet applications, near field communication (NFC) and the like will not be regulated by the PCI standards.

These statements though leave a lot of questions for QSAs.

  • How are QSAs supposed to reference these non-compliant devices in the merchant’s Report On Compliance (ROC)?
  • Do QSAs mark this in the ROC as non-compliant and which requirements do QSAs flag as non-compliant?  Is it because the devices are not PTS compliant or are their other requirements that are not met?
  • Do QSAs need a compensating control for these devices?  And exactly what would the controls be that would make these devices acceptable?
  • Do QSAs need to obtain a letter from the merchant’s acquiring bank(s) acknowledging the use of these devices and their approval of their use?

I am sure this will create many interesting discussions at the PCI Community Meeting that is just a few weeks out.  So stay tuned.


Developers Beware – Stripe

A reader pointed out this merchant services provider to me, so I checked it out.  I ran into some concerns as I reviewed their documentation that I want to share with you all so that you have a better understanding of what Stripe does and provides.

The first thing that I want to point out is why you need to carefully read a service provider’s Web site and understand what is what.  If you look at the Stripe General Questions page there is a discussion of PCI compliance.  Stripe states that they are a PCI certified Level 1 service provider.  What that means is that Stripe’s backend processing of card payments is PCI compliant.  This statement has nothing to do with their Javascript program or any other services that Stripe offers.

But, you say, Stripe provides a Javascript program for processing payments.  What about its PCI compliance?  Good question.  Here is a gray area with PA-DSS compliance of applications.  Because Stripe is not technically selling its Javascript file (it is provided free), I am sure they believe that the Javascript does not have to be certified.  However, the General Questions page is very clear that “Use Stripe.js as the only means by which you accept payment information and transmit it directly to Stripe’s servers.”  To me I would think the required use of the program would imply that the Javascript is required to be PA-DSS certified since developers have no choice but to use it.

That brings up how is Stripe’s Javascript maintained?  What ensures that someone does not change the script and now it starts securely communicating with another server as well as Stripe’s?  This is why PA-DSS certification is necessary for applications because there is too much risk if those applications are not properly maintained and controlled.  All it takes is a single successful attack and every one of Stripe’s customers will pick up a new Javascript that will do whatever the attacker desires.

The next concern I have regarding Stripe is their statement that by using their process, “you completely avoid handling sensitive card data, and keep your systems out of PCI scope.”  Wait a minute.  Stripe states just above that that you need to, “Serve your payment page over SSL.”  That implies that their Javascript runs on your server.  This gets confirmed on their SSL page where they state that their Javascript only communicates with their backend servers over an SSL connection.  It may be their code, but it is executing on your server and that means that your server is in-scope for PCI compliance.

The PCI SSC really needs to get on top of service providers and their claims.  It troubles me that this service provider is making claims that are totally incorrect.  It is these sorts of claims that get good people get into trouble.  Most developers and their organizations do not have the necessary detailed understanding of the PCI standards and therefore trust service providers to be the experts which, in the case of Stripe, they are obviously not experts and are just as clueless.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

February 2023