Can An ISA Sign Off On A ROC Or SAQ?

This question came up recently on one of the LinkedIn PCI groups and drove a lot of discussion.  However, one of the things that concerned me the most is that no one belonging to this group bothered to submit the question to the PCI SSC to be answered.

When such questions come up, the first thing you should do is go to the PCI SSC Web site’s FAQ page to see if the question has already been answered.  There is an amazing wealth of information contained in the FAQs.

If you search the FAQs and you do not come up with an answer to your questions, then submit your question to the PCI SSC.  Technically, anyone can submit a question to the PCI SSC.  However, if you are a QSA in a QSAC, the person listed in your QSAC listing should be the focal point and should submit all questions you have to the PCI SSC.

Questions are submitted to info@pcisecuritystandards.org.  Expect a few days to a few weeks to get a response.  Simple procedural questions such as whether an ISA can sign a ROC or SAQ like a QSA can get a response in a day or two.  Questions that require the PCI SSC to formulate a position, may take a number of weeks before a response is provided.

So, can an Internal Security Assessor (ISA) sign off on a Report On Compliance (ROC) or Self-Assessment Questionnaire (SAQ)?  The answer provided by Cathy Levie, Senior ISA Program Manager, PCI SSC, is as follows.

“The ISA can sign off as long as their Processor/Acquirer has approved of that. This is not up to the PCI SSC.”

In the future, if you have a question and cannot find an answer, ask the PCI SSC.  When you get your answer, please post the answer to any of the PCI groups on LinkedIn or send them to me so that the rest of the PCI world can benefit from the knowledge.  One of the unfortunate issues the PCI SSC has is that not all questions seem to make it into the FAQs or the FAQs are not updated as quickly.

How The PCI Standards Will Really Die

Welcome to the new year.  I hope the holidays have been treating you well and the coming year is good as well.

There have been a number of articles written about why and how the PCI compliance process will die.  It is not that I look forward to the PCI standards dying as they have brought a needed visibility to information security and privacy as well as the fact that PCI keeps me gainfully employed.  However if things stay on their current trajectory, the PCI standards will eventually die, but not for the reasons being quoted in today’s articles.  The real killers of the PCI compliance process will be the card brands and the PCI Security Standards Council.  Yes, the very folks that brought us the PCI standards will bring the ultimate demise of their precious set of standards.

The first death knell I see is that it is very easy to issue edicts from on high when you do not have to implement them.  Over the years, clarifications have been issued, quality assurance reviews performed, forensic examinations conducted and a host of other activities have resulted in “enhancements” to how the PCI standards are assessed and enforced.  Do not get me wrong, a lot of what has been done was needed and appreciated.

However, by the same token, some of what has come down has been a nightmare to implement.  Any QSAC not using some sort of automated system to conduct their PCI assessments will find it impossible to meet the current and any future documentation and tracking standards now required by the PCI SSC’s QA process.  Under the current standards, QSACs need to document who they interviewed and what the persons were interviewed about as well as tying documentation and observations to the tests performed.  Without some sort of automated process, these requirements are just too intensive to perform manually.

Documentation received and reviewed needs to have its file name, date of issue and a description of its purpose in the PCI assessment process documented.  The basic PCI DSS has a minimum of around 200 discrete documents that are required for the PCI assessment process.  The average we see for most of our engagements is over 600 documents which also include not only policies, standards and procedures, but configuration files, interview notes and observations such as screen shots, log files and file dumps.  You really have to question any QSAC that tells you they manually manage the process.  They either have an amazing and magically efficient project management process, they have very, very inexpensive staff (i.e., overseas labor) or they are short cutting the processes and producing a work product that does not comply with the PCI SSC QA program and have yet to be assessed by the PCI SSC (the most likely scenario).

Even using simple SharePoint or Lotus Notes solutions are not cheap when you consider the cost of the server(s) and the storage of all of documentation collected, which can be around 5 to 10GB per project, as well as all of the requisite system maintenance.  Servers and storage may be cheap, but it all adds up, the more clients you assess.  And speaking of the storage of documentation, the PCI SSC requires that documentation related to PCI assessments be stored for at least three years.  For those of us with electronic work paper management systems, this is not a problem.  However, given the amount of paper generated by these projects, those QSACs using the traditional paper filing methods will find a lot of shelf space taken up by their PCI engagements if they are truly following the procedures required by the PCI SSC.

All of this drives up the cost of a proper PCI assessment, more than I think the card brands and the PCI SSC are willing to admit.  It is not that I think the card brands and PCI SSC do not care about this situation, but more related to they do not have an understanding of the operational ramifications of their edicts.  The card brands and PCI SSC tread a very fine line here and to this point they have been heavy handed in the issuing of their edicts.  Going forward, the PCI SSC needs to ask the QSACs, Participating Organizations and ASVs to assess the cost and time impacts of these edicts so that they can be weighed against their benefits versus what is done now which is more of a procedural and proofing review.  If this is not done, there will soon come a point where merchants and service providers will push back hard and refuse to go through the process due to the cost and the amount of time involved to be assessed.

The next death knell is the inane process that is called the PCI Report On Compliance (ROC).  When the PCI SSC did not have access to the QSACs’ work papers, the current ROC writing process made some sense as there was no other way for the PCI SSC or the processors and acquiring banks to know if the QSACs had really done the work they were saying they had done.  However, all of that changed a number of years ago when the PCI SSC required QSACs to add a disclaimer to their contracts stating that the PCI SSC had the right to review all work products.  Yet even with this change, we continue to have to write an insanely detailed ROC, typically numbering in a minimum of 300+ pages for even the most basic of ROCs.

Unfortunately, there are QSACs out there that apparently have not been through the PCI SSC QA process and that dreaded of all states – Remediation.  As a result, they have much lower costs because they are not documenting their assessment work as completely as they need to and are not sampling, observing or interviewing like QSACs that have been through the QA process.  In addition, based on some work products we have seen, they also do not care about the quality of the resulting ROC as it looks entirely like a ‘find and replace’ of a template and makes no sense when you read it.  In talking to other large QSACs that have been through the QA process multiple times, the PCI SSC has indicated that they are monitoring the large QSACs more than the little QSACs because there is more risk with the large QSACs.  While true to an extent, we have encountered a number of smaller QSACs that perform assessments for large clients due to their much lower cost structure and their willingness to ‘overlook’ compliance issues.  If the PCI SSC does not go after these QSACs soon, there will likely be a number of breaches that occur due to the QSACs’ lack of diligence in performing their assessments.

I know of a number of QSACs that would like to see Bob Russo and the representatives of the various card brands to actually work as staff on a few PCI assessment engagements so that they can better appreciate the inordinate amount of work involved in generating a ROC.  I think they would be shocked at the amount of work effort they have driven into a process that is already too complicated and prone for error.

As it stands today, the ROC writing, review and proofing process is probably 50% to 60% of a good QSAC’s project costs.  To address this, the PCI SSC QA group tells QSACs to develop one or more templates for writing the ROC which, from what we have seen from some other QSACs, means a lot of mass ‘find and replace’ to speed the ROC writing process.  For the last few years, a number of QSACs have brought the ROC writing process up at the Community Meetings.  However the card brands continue to shoot down any sort of changes to the process.  As a result, the cost of producing a ROC is driven by the size and complexity of the merchants’ or service providers’ cardholder data environment (CDE).  These costs will only continue to rise as long as the PCI SSC does not allow QSACs to mark items as ‘In Place’ with only a check box and rely on the QSAC’s work papers versus the verbosity required now.  If this sort of process can work for financial auditors, it can work here as well.

A third death knell is the PCI SSC and card brands continuing to quote that the majority of breaches are the result of organizations not complying with the PCI DSS.  In discussions with a number of the PCI forensic examination companies, I am hearing that the card brands cannot believe the fact that more and more organizations were PCI compliant at the time of their breach.  The PCI SSC and card brands have apparently convinced themselves that the PCI standards are “perfect” and they cannot imagine that an organization could be breached unless that organization was not complying with the PCI standards.  There is no security standard that I am aware that totally prevent breaches.  So while the PCI standards are good baseline security standards, the card brands and PCI SSC seem to have forgotten that security is not perfect and that any security standard only minimizes the damage done when a breach occurs if the standard is truly followed.

And as organizations have gotten the PCI “religion,” the effort required to compromise them from the outside via traditional attacks has increased significantly.  As a result, successful attackers have changed strategy and work on social engineering their way past the bulk of an organization’s security measures.  The PCI DSS only has a little bit on social engineering in requirement 12.6 regarding security awareness training.  And even those organizations with the most robust of security awareness programs will tell you that, even after extensive security awareness training, human beings are still fallible and that some people still do very questionable things that continue to put organizations at risk, sometimes significant risk.  Even when you have the most diligent of employees, they still make mistakes in judgment from time to time.

Until the human element can be totally removed, there will always be a certain amount of risk that will never go away.  Again, the PCI SSC and card brands seem to not want to acknowledge the failings of the human element and appear to believe that technology is the savior based on the focus of the PCI standards.  However time and again, every security professional has seen very sophisticated security technologies circumvented by human error or just plain apathy towards security (i.e., “it always happens to someone else, not my organization” or “we’re too small to be a target”).

Until the PCI SSC and the card brands drop the “holier than thou” attitude toward the PCI standards and stop the public pillory of organizations that have been breached, there will continue to be editorial commentary regarding the pointlessness of the standards and ever more serious push back to complying with the standards.

These are the reasons why the PCI SSC and the card brands will be the ones that will kill the PCI standards.  At the moment, they are so far removed from the process; they do not understand how complicated and expensive the process has become which is why merchants and service providers are complaining about the ever increasing costs and effort related to the PCI assessment process.

The PCI SSC and card brands also seem to have forgotten that QSACs have to make money doing these assessments and, when you pile on clarifications and edicts that do nothing to streamline and simplify the process; you are only driving the costs of the process higher.  And higher costs only make merchants and service providers, who are on thin margins to being with, even more incentivized to use the much lower cost QSACs, driving the diligent QSACs out of the market, thus increasing the likelihood of breaches.

Again, it is not that I want the PCI standards to go away as I think they have brought a real benefit.  However, if these issues are not addressed, the PCI standards will end up going away.  I fear that, with them gone, there will be no carrot to ensure the security of cardholder information and we will end up back where we were before the PCI standards existed.

Pre-Authorization Data – The Definitive Answer

Hot off the press from the PCI SSC and this month’s Assessor Newsletter.

Is pre-authorization data in scope for PCI DSS?

PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted, irrespective of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but such data must be protected according to PCI DSS while being stored, processed or transmitted.  Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.

With respect to SAD, PCI DSS Requirement 3.2 prohibits storage of SAD AFTER authorization, even if encrypted. Whether SAD is permitted to be stored prior to authorization is determined by the individual payment brands, including any related usage and protection requirements.  Any permitted storage of SAD prior to authorization would be subject to strict conditions and controls above those defined in the PCI DSS.  Additionally, several payment brands have very specific rules that prohibit any storage of SAD and do not make any exceptions. To determine payment brand requirements, please contact the individual payment brands directly.

There we have it.  Pre-authorization data is in-scope with a number of caveats as dictated by the individual card brands.

Just to be clear, I have never argued that pre-authorization data was not to be secured with the same diligence as post-authorization data.  I just could not find anything in the PCI DSS that explicitly called out the coverage of pre-authorization data.  Past training had always explicitly referenced that the PCI DSS was for data stored after authorization, i.e., post-authorization.

Now I guess I am off to bug the card brands about their pre-authorization data retention rules if they are not posted out on their merchant security Web pages.

Unintended Consequences

Why reinvent the wheel?  This is from the June 2012 Assessor Update published by the PCI SSC.  It provides advice for those situations when people are foolish and transmit their cardholder data to your organization in ways you would prefer they do not use.  While focused on the merchant, these recommendations can be followed by all organizations that need to be PCI compliant.

What should a merchant do if cardholder data is accidentally received via an unintended channel?

Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.

In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data.

Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include:

•   Implementing controls to prevent acceptance of cardholder data via unsecured channels
•   Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data
•   Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data

Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant’s CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted.

If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant’s personnel should be trained to not ‘reply’ using the same email that contains the cardholder data.
Instead, the merchant’s personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data.  This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.

Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant’s secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.

A Reason Why The PCI Standards Get No Respect

Call it the “Rodney Dangerfield Effect.”  Conflicts of interest seem to pervade the PCI compliance process and it is something the PCI SSC and the card brands need to clear up before their precious standards get even more bloodied in the media.

I have run across another processor that dictates the use of a particular QSAC.  Now do not get me wrong, I am a capitalist and interested in making money just like the other guy.  But I have to say that I am not a shark like some of my competitors.  I know this post will sound like someone bemoaning sour grapes but, in my opinion, this situation just makes the whole PCI compliance process look like a worthless sham.

What prompts this post is a call with one of our clients that we have performed PCI assessments for years, even before the PCI SSC existed.  They are implementing a new point of sale (POS) terminal that requires them to use a different credit card transaction processor because their existing processor is not yet certified to process transactions from this new terminal.  Fair enough.

The new terminal is a test installation to see if the service should be expanded to all of our client’s locations.  Since the terminal will only generate a couple of thousand transactions in the coming year, the new processor has identified our client as a Level 4 merchant and is treating them accordingly.  In reviewing the processor’s contract, our client found that the contract dictates that they use a specific QSAC to “assist” them in filling out their PCI Self-Assessment Questionnaire (SAQ) A.  Knowing the SAQ A, our client cannot figure out what a QSAC would do to assist, but it is in the processor’s contract.

Our client’s first question was, “Since when does a processor have the right to force us to use a particular QSA?”  We explained that we have been told that while the PCI SSC and the card brands allow processors to have rules that go above and beyond the PCI SSC’s and card brand’s requirements.  While I understand that the processor is likely trying to ensure that their Level 4 merchants are not just checking the ‘Yes’ box on their SAQs, forcing the use of a particular QSAC seems a bit questionable.  Particularly when we have been told that some QSACs are giving processors payments for all of the customers they refer.

I have written about this issue before with processors charging fees to merchants for the filing of their SAQs.  There is also the scam of forcing merchants to use a specific PCI Approved Scanning Vendor (ASV) to scan the merchant’s networks even when the merchant does not have an ecommerce presence or outsources their ecommerce to a third party that already provides their ecommerce customers ASV reports.  This is just one more questionable requirement that processors demand that makes merchants and the media think PCI is a scam.

Their next question was, “Since you already do our ROC, can’t we just submit that to our new processor?”  You can do that, but you need the new processor’s approval as they do not have to accept our work.  What is the likelihood that the new processor will accept our client’s ROC?  No idea and I am anxious to hear what our client tells us in that regard.

The problem here is that the processor in question and the QSAC have numerous connections that give a distinct impression of conflicts of interest.  First, the QSAC in question runs the processor’s Level 4 merchant compliance program.  That program dictates that the QSAC perform some sort of assessment process in order for any of the processor’s Level 4 merchants to create and submit their SAQ.

The justification the processor gave our client was that the PCI SSC requires this action.  Last I checked, the PCI SSC and the card brands did not require a QSA to fill out an SAQ.  MasterCard has a deadline of June 30, 2012 for Level 2 merchants to have either an ISA fill out their SAQ or have a QSA conduct a PCI ROC.  Until October 2010, Visa Canada required that a QSA sign off on all SAQs.  But those are the only SAQ rules involving QSAs that I am aware.

Next, the QSAC and the processor have swapped various personnel over the years.  As a result, there is an appearance that the two are essentially one in the same given that the QSAC runs the processor’s compliance program and the processor dictates that their merchants use the QSAC for PCI assessments.  I know that people move between organizations in the same industry all the time, but the number of people that have gone between these two would seem to be higher than expected.

I guess since I am an employee of a public accounting firm in the United States, I have greater sensitivity to conflicts of interest than most.  The American Institute of Certified Public Accountants (AICPA) has very specific rules in regards to conflicts of interest.  We have an entire department dedicated to ensuring that we avoid conflicts of interest.  As a result, we regularly look at the services provided to our clients and ensure that we are not in conflict or even give an appearance of a conflict of interest.

Now I am not suggesting that the PCI SSC and card brands go to the levels that the AICPA requires.  But let us face it, it is the Wild West out there and some of the QSACs do not care what conflicts they may have and how it might hurt the PCI compliance processes.  The PCI SSC only requires its assessors document the services they provide to the organizations they assess in their assessment reports.  While that offers a certain amount of transparency, when you read some of these ROCs, it becomes painfully obvious that some QSACs are assessing their own security services.  In some cases, the organization being assessed has outsourced almost everything related to their PCI compliance to the QSAC doing their assessment.  What do you think the likelihood is that those services will be assessed as not compliant if there are compliance issues?  One would assume it will be very unlikely.

But it can get even worse.  A certain QSAC operates one of the card brand’s merchant PCI compliance program.  Merchants submit their Attestations of Compliance (AOC) and Reports On Compliance (ROC) to this card brand through the QSAC which manages the process.  Does this QSAC inform their clients that accept this card brand’s cards of this fact?  Not that I have ever been told by any prospects.  Does the QSAC list the management of the card brand’s merchant program on their ROCs?  Not that I have seen and I have seen a number of their ROCs for merchants that accept the card brand’s cards and I have never seen the program listed.  Does the QSAC submit their ROCs to the program that they manage?  They must as the ROCs I have seen are from merchants that accept the card brand’s cards.  Is this a conflict of interest?  One would think, but this is how things operate today.

The bottom line is that in this age of openness and transparency, it is these sorts of relationships and actions that give a very bad impression to the outside world.  The PCI SSC and the card brands need to enhance their rules for QSACs that define conflicts of interest.  Until this is done, the PCI standards will continue to be ridiculed and viewed as pointless.

Another Year, Another QSA Re-Certification

It is that time of the year when I have to go through the PCI SSC’s Qualified Security Assessor (QSA) re-certification process.

To add to the re-certification process this year, I have been sick for the last two months with a cold that turned into a nasty case of bronchitis along with laryngitis that then caused a severe case of sinusitis.  I just could not catch a break this Spring.  The good news is that I am finally on the mend and should be back to normal in another couple of weeks.

However, even illness does not get you out of the QSA re-certification process.  So, I put it off as long as I could and took the examination this morning.

As I expected, there was not a lot of new material in this year’s QSA update.  The biggest focus of this year’s training seemed to be:

• The interrelationship of the various PCI standards;
• Roles and responsibilities of QSAs, ASVs, merchants, service providers, acquirers, PCI SSC and the card brands;
• Scoping of the cardholder data environment and cardholder data discovery; and
• The integration of the PA-DSS with the PCI DSS.

Other than that, it was for the most part a reinforcement of the changes in the PCI DSS v2.0 to make sure that QSAs really understand the standard.

There is an interesting section on what not to write in the In Place column.  The unfortunate aspect about this section of the training was that the examples that were presented were straight out of ROCs that the PCI SSC QA program had reviewed.  Some of those responses were very difficult to read they were so bad.

There is also a discussion on network segmentation.  Unfortunately, the examples were very simple.  I wish our clients had such simplified networks.  However, because this discussion is in this year’s presentation materials indicates there are apparently still a lot of QSAs that do not understand the concept of network segmentation and what constitutes good segmentation from poor segmentation.

As I am finishing this post, I have been told I passed the QSA re-certification examination.  So I am a QSA for another year.

When Will The PCI SSC And Card Brands Stop The Mobile Payment Insanity?

This week PayPal introduced Here, their mobile payment processing application for Apple iOS and Android devices.  The good news is that PayPal Here at least appears to encrypt cardholder data, but that appears to be the extent of the good news.

If you pay attention to the latest Suzie’s Lemonade Verizon Wireless advertisement, you will see Intuit’s GoPayment solution on a tablet computer processing a payment.  In another bit of good news, the Intuit GoPayment solution is also encrypted.

But what is most disconcerting is that this is just another in a string of mobile payment processing solutions to be introduced with no way of knowing whether or not the security claims are accurate or can even be trusted.  This is because the PCI Security Standards Council halted last year the certification of any of these mobile payment processing solutions through the PIN Transaction Security (PTS) and Payment Application Data Security Standard (PA-DSS).  Do not get me wrong, the Council was in a tough spot and did not have a plan as to how to deal with these solutions, so the called a halt while they went back and reassessed things.

However the marketplace is not waiting.  So while the marketplace continues to deliver solutions, the merchant is left to their own devices to know whether any of these mobile payment processing solutions can be trusted.  And what I am fearful of is that small merchants, who are the marketing target of these solutions, will be put out of business should the device somehow be compromised or they lose a device.

So what are the questions surrounding the PayPal Here?

First, what is the encryption algorithm that is used?  I am guessing that they are using DUKPT, as that is common with these sorts of devices, but it is something that should be explicitly identified in their FAQ.  What PayPal currently says is, “… the PayPal Here card reader is encrypted and is backed by over a dozen years of experience of providing buyers and sellers the highest levels of security.”  If they are using DUKPT, can the key be changed?  Most of the mobile solutions I have seen do not allow for the key change under DUKPT which could be a problem.

Then there is the fact that you can manually enter a cardholder’s information through the iOS/Android application.  Given the fact that these systems are notorious for having keyboard loggers of industrial strength that means that any manual input will be recorded in the device.  I am guessing that would include cardholder name, PAN and expiration date.  However, if PayPal Here collects the CVV/CVC/CID value in manual entry that would be an extremely bad thing as the device will retain that until it overwrites it months later.  Again, there is no documentation to determine what is allowed to be manually entered, so we cannot assess how much risk this might introduce.

But the scariest feature of the PayPal Here is unrelated to credit cards; it is the remote capture of checks.  PayPal Here allows the merchant to scan a check and then submit it to their financial institution.  Again, given the data retention of these devices, I can only guess that the check images processed through the PayPal Here application will remain on the device until the space is needed which could be months.  The problem with all of this is that if people think credit card security was questionable, check processing security is nonexistent.  As a result, anyone with a modicum of knowledge could use the check information on one of these devices to drain every bank account stored.

Let us hope that the PCI Security Standards Council and the card brands quickly get back to certifying these applications so that merchants are not using insecure payment solutions.

PCI DSS Compliance Certificates

In this month’s PCI SSC QSA Newsletter, the FAQ of the Month is about so called ‘PCI DSS Compliance Certificates’.  I started to hear about these a couple of years ago, but it got really big last year when I started running into processors and acquiring banks demanding them.  I had a particularly troubling conversation with a processor who demanded that we produce one for one of our clients.  When offered the PCI DSS Attestation Of Compliance (AOC), this processor acted as though we were trying to put something over on them.  When I asked him where I was supposed to get such a certificate when it does not exist on the PCI SSC Web site, he accused me of not being a QSA because all QSAs know what the certificate looks like and where to get it.

As a result, a lot of QSAs must have submitted a question regarding these certificates like I did.  Here is the PCI SSC’s response.

“In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council.  However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading.  Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands.

The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.”

So all of you processors and acquiring banks that seem to think the only acceptable proof of PCI compliance is some mystical PCI DSS Compliance Certificate, stop demanding them.  They do not exist and never have existed.  The document you need for proof of PCI compliance is the Attestation Of Compliance (AOC), period.  All self-assessment questionnaires (SAQ) contain the AOC and there is a separate AOC form for those submitting a Report On Compliance (ROC).

And all of you QSAs and ASVs out there differentiating yourselves because you produce these nice, but essentially worthless, certificates, stop misinforming merchants, processors and acquiring banks by implying that QSAs and ASVs not producing such a certificate are somehow doing something wrong or worse, dishonest.

Now that the PCI SSC has clarified this situation, hopefully, this marketing ploy will stop.

Google Wallet

Good news for anyone considering using Google Wallet.  Google Wallet encrypts the PAN and only stores the last four digits of the PAN in clear-text according to a forensic assessment conducted by ViaForensics.  The other piece of good news from ViaForensic’s examination was that drive by attacks against Wi-Fi or near field communications (NFC) to intercept Google Wallet communications appear to fail.

Based on ViaForensic’s analysis, it appears that Google Wallet would likely comply with the PA-DSS.  The full PAN is encrypted and communication of the PAN via Wi-Fi or NFC is secured.  Granted there are a lot of other PA-DSS requirements that we do not have a window into that may or may not be PA-DSS compliant.  But on the whole, I would have to believe that Google Wallet would be PA-DSS certified.  So, why is Google Wallet not PA-DSS certified?

First and foremost, in the eyes of the PCI SCC and the card brands, Google Wallet and similar applications are storing pre-authorization data and are just an electronic representation of someone’s traditional wallet.  The PCI SSC does not certify traditional wallets, so why would they certify electronic wallets?  As a result, the PA-DSS does not apply.  Should Google and other vendors of electronic wallets ensure the security of cardholder data?  No doubt about it.

But a more important reason that the PCI SSC is backing away from certification is related to the other findings in ViaForensic’s report.  Their analysis also uncovered some not so good news in that Google Wallet stores a lot of personally identifiable information (PII) unencrypted.  This PII includes such information as cardholder name, expiration date, credit limit and account balance.  I think most people would now start to understand why the PCI SSC backed away from certifying such applications.

The PCI SSC does not want to be on the hook for the unsecured PII.  If the PCI SSC were to certify Google Wallet as PA-DSS compliant, I am sure their lawyers informed them that such a certification would drag them into lawsuits involving the exposure of the unsecured PII even though the PA-DSS does not cover PII outside of the PAN.  Their lawyers probably advised them that a PA-DSS certification would likely imply to users of these electronic wallet applications that their PII was included in the PA-DSS certification.  As a result, the PCI SSC and card brands would likely have to launch a massive and costly educational campaign to explain to the public that the PA-DSS certification was only related to protection of a cardholder’s PAN and nothing else.  And even with such a campaign, the PCI SSC would likely still get dragged into lawsuits over peoples’ PII being exposed.

And the likelihood of such lawsuits is very high.  Smartphones are regularly lost and the security protecting them is almost non-existent, if security is even enabled.  A hacker can easily take a lost smartphone and obtain enough information to perform identity theft.  Hackers could even decrypt the PAN given the high likelihood that the PIN to decrypt the PAN could be derived from other information on the smartphone.  The nightmare scenario would be development of malware delivered through the smartphone’s application store that harvests the PII.

At the end of the day, there is just too much risk involved in certifying such applications because there is just no way to manage the risk.  So those of you thinking the PCI SSC should certify these applications need to rethink your position.

FYI  This is my 200th post.  I never guessed that this blog would last this long and I want to take this time to thank all of you for keeping this going.

Kicked Out Of “The Club”

It has finally happened.  A Qualified Security Assessor Company (QSAC) has finally had their status revoked by the PCI SSC.  In a little noticed release dated August 4, 2011, the PCI SSC announced through an FAQ that as of August 3, 2011, Chief Security Officers (CSO) of Scottsdale, Arizona is no longer a QSAC.  To add insult to injury, CSO was also a Payment Application Qualified Security Assessor Company (PA-QSAC) as well and that status has also been revoked.  In reviewing CSO’s Web site, all references to merchant and application assessments have been removed which was likely required by the PCI SSC with the revocations.  These revocations are pending any appeal by CSO and only they know if an appeal will be mounted.

The PCI SSC did not explicitly share the reasons why CSO’s statuses were revoked.  But based on what little information is in the FAQ, it seems to imply that CSO was not able to provide documentation that supported their conclusions regarding the assessment opinions in their Reports On Compliance (ROC) and Reports On Validation (ROV) they had issued.  While there is no public way to determine the number of ROCs that CSO has issued, in reviewing the PA-DSS certified applications list from the PCI SSC Web site, CSO had issued around 56 ROVs for payment applications.

What is interesting about this whole situation is that the PCI SSC issued the announcement as an FAQ versus the usual press release.  From the FAQ, we now know something about the revocation process.

• First and foremost, it seems that the PCI SSC is finally showing its teeth regarding their quality assurance assessment process.  The FAQ states, “CSO’s status as a QSA and PA-QSA was revoked only after careful review of reports and evidence submitted as part of the quality assurance program …”.  The implication here is that CSO was unable to provide sufficient evidence that supported the conclusions of their assessments.  The reason this is important is it seems to indicate that the PCI SSC is now including a review of work papers to determine if QSACs are collecting evidence that supports their conclusions in the Report On Compliance (ROC).

• The FAQ states, “It accompanies CSO’s inability to demonstrate sufficient improvement through a prior remediation process.”  CSO had already been through the QA process once and had to go through remediation as a result of the prior QA review.  CSO must have gone through the remediation process within the last two years as it was two years ago when the QA process started.  Even after going through remediation, CSO was apparently not able to get through the QA assessment without being placed in remediation again.  What is unclear is whether a QSAC is not allowed to go through remediation twice in a row or if the CSO situation was the outgrowth of larger QA issues that could not be corrected.
• The FAQ states that ROCs and ROVs issued by CSO and accepted by the card brands and the PCI SSC are still valid, but that any work in process will need to be conducted by a different QSAC or PA-QSAC.  What I find interesting here is that while the PCI SSC QA process found that CSO was not doing their job as a QSAC or PA-QSAC, merchants and others are to accept their previously issued work and results.  That seems a bit too flexible in my opinion.  If CSO’s status as a QSAC and PA-QSAC has been revoked, particularly for being unable to support their conclusions, then why should any organization accept their conclusions on any previous assessments?  I am particularly concerned about any payment applications certified as PA-DSS compliant.
• One thing implied by the FAQ but not explicitly stated is that all of CSO’s employees that had a QSA designation are no longer QSAs.  As a result, based on my understanding of the QSA rules, they cannot go to another QSAC to retain their QSA status.
• Finally, CSO has an opportunity to appeal the PCI SSC’s revocation of the QSAC and PA-QSAC status.  However, as of this writing, I have not seen anything in the press that would indicate that an appeal has been requested.

It will be interesting to see if CSO appeals this decision or just accepts the Council’s ruling.