Virtual Payments

Virtual payments are becoming more and more prevalent outside of the insurance industry as companies realize the convenience of paying virtually.  As a result, more business-to-business (B2B) purchases are being paid for via virtual payments.  It also became obvious at our latest PCI Dream Team session that virtual payments need to be better explained to people so that they understand how they work and their responsibilities for security.

Definition

Technically virtual credit cards have existed for a while.  Businesses have had “virtual” credit cards for making airline and hotel reservations, purchasing office supplies and paying for other business expenses for decades.  The cards do not physically exist (originally they did exist, but this was seen as a security risk), but the business’ accounts payable department had a virtual card with a PAN, card verification code and expiration date issued by Visa, MasterCard or American Express for paying merchants for goods or services.

A virtual payment (or virtual credit card) is essentially the same as a regular, physical credit card with the following exceptions.

• The primary account number (PAN) can only be used once to make a payment. If you mess up either of the next two criteria, that does not count as a ‘use’.  That said, even if everything is correct and the payment is declined you will have to contact the organization that generated the virtual payment to get a new virtual payment created.  Also, be careful with a virtual card PAN as some processors may generate a PAN that will not Luhn check.
• Only the merchant defined on the virtual payment can use the payment. For example, if the merchant on the virtual payment is defined as ‘ABC Company’, only ABC Company can submit the transaction for payment.
• The payment must total exactly to the total authorized on the virtual payment. For example, if the virtual payment is for $1,252.98 USD, then the merchant can only submit a charge for $1,252.98 USD for payment.
• Virtual payments are flagged as being virtual. So, if someone were to copy the information and put it on a physical card to use physically at a retail outlet, the card would be declined.

How Do Virtual Payments Work?

Virtual payments are typically created by transaction processors such as Chase Paymentech, Elavon or Worldpay.  Although there are a number of independent sales organizations (ISO) and others that have affiliated themselves with processors to also generate such payments.

A lot of accounts payable software solutions now provide connections to transaction processors’ APIs for the generation of virtual payments to pay bills.  You will have to check with the application vendors to determine whose virtual payment solutions their applications support.  But the original way of using a Web browser to access the processor’s virtual payment application is also available.

An organization must sign up for virtual payment services, so it is not something that you can just access.  In addition, it is the responsibility of the organization to manage the users that have the ability to generate virtual payments as well as establish the minimum/maximum transaction amounts, time payments are valid (typically 30 to 90 days) and other payment criteria.  In addition, the solution may also specify the merchants that can be paid through the virtual payment solution.  Once set up, an organization can then generate virtual payments to pay their bills.

One very important step before you start generating virtual payments is that you need to ensure that the organizations you are paying will accept virtual payments or payment cards.  While an organization may have retail outlets that accept payment cards for payment, does not mean that their commercial operations also accept payment cards.  As such, you need to contact the accounts receivable department at the organizations you intend to pay with a virtual payment to ensure that they will process the virtual payments as some organizations cannot or will not.  Also use this as an opportunity to confirm you have the correct name of the organization (as it appears when they process card payments), the correct facsimile number, correct email address (I recommend you get both just in case) and the preferred method of sending the virtual payment (i.e., facsimile or email).  Keep in mind it is not your problem to worry about the payee’s PCI compliance in how they handle your payment.  That is their problem, not yours.

When a virtual payment is generated, it is typically sent to the payee via facsimile.  However, I have also heard that some processors that can send the information via secure email services such as Proofpoint or MimeCast.

If you are accepting virtual payments, you need to be aware of the PCI compliance issues with facsimile.  The problem with using facsimile is that a lot of organizations have implemented facsimile services such as HelloFax, MyFax or eFax and any facsimile messages are automatically delivered to users via corporate email.  Such a solution as eFax brings an organization’s email system into scope for PCI compliance.  As a result, it is important that if your organization will accept virtual payments that those facsimile transmissions are sent to a secure physical facsimile machine located in the area where those payments will be processed.  I have some clients that use secure printing solutions for printing their facsimiles where the user has to use their building HID card to securely print output on any printer.

Secure email solutions will hold the message for the payee to obtain from the secure email Web site interface via a browser.  The secure email solution will send you a notification that you have received a secure message along with a link to that message.  Once you get into the secure email solution, it is up to your organization to ensure you maintain the security of the message and the SAD sent to you.  So, no forwarding the message to your own email system.  No storing message attachments (likely the SAD) to a PC or network drive.  Print out the message and/or attachments to a physical printer and process the payment from those printouts.

SAD Is SAD – CHD Is CHD

As I said earlier, virtual payment messages contain SAD in the form of card verification value in addition to the PAN, expiration date and cardholder name which are cardholder data (CHD).  Just because we are talking about virtual payments and they can be used only once does not mean they can be treated any differently than the same information from a physical payment card.

That said, Visa and MasterCard have their own view of virtual payment information security.  As David Mundhenk reminded everyone on our latest Dream Team session, the card brands also have their own rules in addition to the PCI standards.  So, it is important for everyone to look at the card brands’ rules as well as the PCI standards when dealing with SAD/CHD.  That means not only their security programs, but also their respective Merchant Agreements and asking them questions when you cannot find the answers in any of their official documents.

In the case of virtual payments, Visa and MasterCard differ on security of virtual payment information.  Unfortunately, you would not know that fact if you had not asked each of the brands about this subject because their security programs and merchant agreements do not address the subject.  For the record, American Express and JCB do not have an opinion on the subject.  Obviously SAD is SAD before it is used to process the payment, where the difference comes is after the payment is processed.

Visa wants the information protected even after the payment is processed.  They demand that it be securely destroyed after the payment is processed even though the information is single use.  I kid you not, MasterCard said on a call that if my client wanted to post the printed facsimile on a utility pole out in public, that was okay with them because the information could not ever be used again.  Talk about two polar opposite approaches.  As a result, I recommend following Visa’s recommendation and securely destroy the original message or attachment.  If for whatever reason you need to keep the payment document, securely redact the information, take a copy of the redacted original for your records and then destroy the redacted original.

That is what you need to know about virtual payments.

Advertisement

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.

The Requirement 3.2.1 – 3.2.3 Not Applicable Debate

When v3.2 of the ROC Reporting Template came out the QSA/ISA community noticed that requirements 3.2.1 – 3.2.3 could no longer be marked as ‘Not Applicable’.

The rationale the Council gave when they explained why they disallowed ‘Not Applicable’ for these requirements is that they wanted QSAs/ISAs to have to explain what procedures they had followed to confirm that organizations were not storing sensitive authentication data (SAD) in the form of track data, card verification values or PIN blocks.

The push back from QSAs and ISAs was to ask how that was relevant when an organization’s card processing could not come into contact with such information as when P2PE had been implemented?

The Council has long stated that for Level 1 merchants that have, for example, implemented a P2PE solution, they should follow the requirements in SAQ-P2PE to fill out their ROC and mark any requirements not in the SAQ-P2PE as “Not Applicable.  The merchant uses a P2PE validated solution and the requirement is not relevant.”

This Council guidance resulted in the question at the 2016 Community Meeting Assessor Session, “How do you do that for requirements 3.2.1 – 3.2.3 when they cannot be marked ‘Not Applicable’ and do not appear in SAQ-P2PE?”  “Good question.  We will have to get back to you.”, the Council told attendees.

Well, here we are two years and a new version later and these requirements still cannot be marked as ‘Not Applicable’.  A number of people texted me at this year’s Assessor Session to bring this issue up again, but I was tired of arguing and just let it go.

The more I have thought about it, the more I regret not bringing this issue up because it needs to be addressed.

So, if someone attending the Assessor Session at the European or APAC Community Meeting would like to bring this question up, I would appreciate it as would a lot of the QSA/ISA community.

2018 North American PCI Community Meeting Thoughts

It was an interesting time in Las Vegas this year.  Part of that is due to the fact that we are in Las Vegas.  But part of it was that the Community Meeting seemed to be devoid of the usual anticipation for the Community Meeting and expected pronouncements.  While there were announcements for various standard updates, these were well anticipated and were not a surprise.  Some of the slide decks have been released, but others will not be available until the European Community Meeting is held in a few weeks.

While there were a number of good presentations this year, in my very humble opinion, the best session was the Assessor Session at the end of the meeting.  The good news this year was that a lot of QSAs and ISAs made sure to stick around for this session.  There were a number of good questions asked after the Council’s presentation, but I will wait for the Council’s transcript to be published before weighing in on those.

As in years past, the Council had a presentation at the start.  The following are highlights from that presentation.

AQM Program Highlights

As usual, the AQM team did a bang-up job pointing out common issues found in the various assessment types they review.

On the PA-DSS side of the ledger, a lot of PA-QSAs are having issues with requirement 5.1.6.b regarding application least privilege.  The Council clarified that what they are looking for in this requirement is proof that the application does not run as ‘root’, ‘administrator’ or some other default privileged account in order to run properly.

For P2PE assessments, there have been issues regarding when a double length 3DES key can be used.  The Council explained that a double length 3DES key is only allowed when using derived unique key per transaction (DUKPT).  All other uses must be triple length keys to be in compliance with P2PE.

Apparently, QSAs and their QA minders are totally missing what is meant by “describe how”.  When describing “how” a QSA must describe all of those procedures used to determine the requirement was satisfied as well as how those procedures prove the requirement was met.

QSAC QA manuals still are not covering topics such as evidence retention and destruction, security incident response plans and code of conduct policy.  The Council reminded everyone to make sure all topics in the QSA Qualifications Requirements document are covered.

Compensating controls were a continuing problem area and that should not be a surprise.  I am constantly fascinated when I receive a ROC for proof of PCI compliance performed by another QSAC and get to see what passes for a valid compensating control worksheet (CCW) at other firms.  Apparently ‘intent and rigor’ of the requirement and ‘above and beyond’ are foreign phrases to a lot of QSAs.  Never mind the fact that the controls used, tested and maintained are usually vague in description.  The Council pointed people to their Portal for remedial training of QSAs that cannot comprehend writing a CCW.  I have written a number of posts on compensating controls.  If you want to write good CCWs, start here for the most current post and it will point you to prior posts.

The Council got some interesting questions from QSAs over the year.  The first one is one that a lot of clients ask us, “Do you really have to come onsite?”  Yes, an onsite visit by the QSA is actually required.  However, how long a QSA needs to be onsite can vary from as little as a couple of days for a long-time client to a week or more for a new client.  Onsite visits can be supplemented by video meetings when needed.  Not unusual these days when a client has worldwide operations and not everyone is located at headquarters or will not be available when the QSA is onsite.

The other question was regarding ROC and AOC dates.  How people keep messing these up is beyond me, but as with the CCWs, I see a lot of ROCs and AOCs out of other firms where the dates on the documents are not consistent.  Basically, the last thing any QSAC should do is to set all of the dates in the ROC and AOC to match as part of their document finalization processes.  That way you will avoid this problem.

There was a brief discussion of the Software Security Standard (S3) that will replace the PA-DSS.  Most of the discussion revolved around the proposed timeline.  The standards themselves will be published sometime before year end.  Reporting materials will be published around mid-2019 with training commencing in the Fall of 2019.  The big deadline is that PA-DSS Reports On Validation (ROV) will only be accepted through mid-2020 requiring all reports going forward to be under the S3.  That will mean that by mid-2022, all PA-DSS validated applications will move to “Acceptable for Pre-Existing Deployments”.

Finally, SSL and early TLS got a discussion.  Somehow the word has not gotten around that if a company still uses SSL and/or early TLS, there must be a compensating control developed for the relevant requirements since Appendix A2 no longer exists in v3.2.1 of the DSS.  They also reminded everyone that having SSL or early TLS is NOT an automatic fail.  However, vulnerability scans will have to have explanations developed justify the use of the protocols as well as what is done to mitigate their use.

Card Production Security Assessor Program

If you were not aware, the PCI SSC took over the various card brands’ card production programs and created a single common program similar to what the Council did with the Data Security Standard back in 2006.

In response the Council is creating a new assessor program in 2019.  Card Production Assessor Companies (CPAC) will not need to be existing QSACs nor will assessors need to be QSAs.  The new assessor training program will be rolled out next year for this standard.  The Council did note that existing card production assessors will be somehow recognized by the new program but did not specify how that recognition would be implemented.

As with QSACs and QSAs, the Council will maintain a database of CPACs and qualified card production assessors.

PIN Assessor Program

As with card production, the Council has also been responsible for PIN standards for a few years now.  As a result, the Council is developing a program for creating PIN Assessor Companies and PIN Assessors.

There will be no need for the PIN Assessor Company to be a QSAC nor will assessors be required to be QSAs.  This program will also start in 2019.

Global Executive Assessor Roundtable (GEAR)

This is a new group that was established this year.  Its role is to provide a direct communication channel between the PCI SSC and 20 qualified security assessor companies’ (QSAC) senior executive leadership.  This group met for the first time a few days before the start of the Community Meeting.  Each member of GEAR serves for a two-year term.

The 20 QSACs on the GEAR are:

• @sec
• Advantio
• Coalfire
• Control Case
• Foregenix
• IBM Security
• isec
• K3DES
• nccgroup
• Protiviti
• PSC
• RSM
• Security Metrics
• Shellman
• SISA
• Sysnet
• Trustwave
• UL
• usd
• Verizon

As usual, it was great catching up with everyone and meeting new Guru fans.  I really appreciate all of the great comments about the blog.  Even though I see the statistics for the blog, it still amazes me how many people read it and appreciate it particularly when you meet so many of them in person.  It is very humbling.

Hopefully I will see you all next year in Vancouver.