Security Or Checking A Box?

“Better to remain silent and be thought a fool than to speak out and remove all doubt.” Abraham Lincoln

What is your organization interested in?  Security or checking a box?

Not surprisingly, most people answer “security” and then go on to prove with their actions and words that they are only interested in checking a box.

For all of you out there that argue ad nausea about the meaning of PCI DSS testing requirements and the requisite documentation are interested in one thing and one thing only; checking a box.  I am not talking about the few that have honest differences of opinion on a few of the requirements and how a QSA is interpreting them and assessing them.  I am talking about those of you that fight constantly with your QSA or acquiring bank on the process as a whole.

If you were to step back and listen to your arguments, you would hear someone that is splitting hairs in a vain attempt to avoid having to do something that would improve your organization’s security posture.  In essence, you want to only be judged PCI compliant, not actually be secure.

To add insult to injury, these are also typically the people that argue the most vehemently over the fact that the PCI DSS is worthless because it does not make an organization secure.  Wow!  Want to have your cake and eat it too!  Sorry, but you cannot have it both ways.

Everyone, including the Council, has been very clear that the PCI DSS is a bare minimum for security, not the “be all to end all” for securing an organization.  Organizations must go beyond the PCI DSS to actually be secure.  This where these people and their organizations get stumped because they cannot think beyond the standard.  Without a detailed road map, they are totally and utterly lost.  And heaven forbid they should pay a consultant for help.

But I am encountering a more insidious side to all of this.  As you listen to the arguments, a lot of you arguing about PCI compliance appear to have no interest in breaking a sweat and doing the actual work that is required.  More and more I find only partially implemented security tools, only partially implemented monitoring and only partially implemented controls.  And when you dig into it as we must do with the PCI assessment process, it becomes painfully obvious that when it got hard is when the progress stopped.

“It’s supposed to be hard. If it wasn’t hard, everyone would do it.” Jimmy Duggan – A League Of Their Own

Security guru Bruce Schneier was speaking at a local ISSA meeting recently and when asked about why security is not being addressed better he stated that one of the big reasons is that it is hard and complex at times to secure our technology.  And he is right, security is hard.  It is hard because of our poor planning, lack of inclusion, pick the reason and I am sure there is some truth to it.  But he went on to say that it is not going to get any easier any time soon.  Yes, we will get better tools, but the nature of what we have built and implemented will still make security hard.  We need to admit it will be hard and not sugar coat that fact to management.

Management also needs to clearly understand as well that security is not perfect.  The analogy I like to use is banks.  I point out to people the security around banks.  They have one or more vaults with time locks.  They have video cameras.  They have dye packs in teller drawers.  Yet, banks still get robbed.  But, the banks only stock their teller drawers with a minimal amount of money so the robber can only get a few thousand dollars in one robbery.  Therefore to be successful, a robber has to rob many banks to make a living which increases the likelihood they will get caught.  We need to do the same thing with information security and recognize that breaches will still occur, but because we have controls in place that minimizes the amount or type of information they can obtain.

“There’s a sucker born every minute.” David Hannum

Finally, there is the neglected human element.  It is most often neglected because security people are not people, people.  A lot of people went into information security so that they did not have to interact a lot with people – they wanted to play with the cool tools.  Read the Verizon, Trustwave, etc. breach analysis reports and time and again, the root cause of a breach comes down to human error, not a flaw in one of our cool tools.  Yet what do we do about human error?  Little to nothing.  The reason being that supposedly security awareness training does not work.  Security awareness training does not work because we try to achieve success only doing it once per year not continuously.

To prove a point, I often ask people how long it took them to get their spouse, partner or friend to change a bad habit of say putting the toilet seat down or not using a particular word or phrase.  Never in my life have I ever gotten a response of “immediately”, “days” or “months”, it has always been measured in “years”.  And you always get comments about the arguments over the constant harping about changing the habit.  So why would any rational person think that a single annual security awareness event is going to be successful in changing any human habits?  It is the continuous discussion of security awareness that results in changes in people’s habits.

Not that you have to harp or drone on the topic, but you must keep it in the forefront of people’s mind.  The discussion must be relevant and explain why a particular issue is occurring, what the threat is trying to accomplish and then what the individual needs to do to avoid becoming a victim.  If your organization operates retail outlets, explaining a banking scam to your clerks is pointless.  However, explaining that there is now a flood of fraudulent coupons being generated and how to recognize phony coupons is a skill that all retail clerks need to know.

• Why are fraudulent coupons flooding the marketplace? Because people need to reduce expenses and they are using creative ways to accomplish that including fraudulent ways.
• What do the fraudulent coupons do to our company? People using fraudulent coupons are stealing from our company.  When we submit fraudulent coupons to our suppliers for reimbursement, they reject them and we are forced to absorb that as a loss.
• What can you do to minimize our losses? Here are the ways to identify a fraudulent coupon.  [Describe the characteristics of a fraudulent coupon]  When in doubt, call the store manager for assistance.

Every organization I know has more than enough issues that make writing these sorts of messages easy to come up with a topic at least once a week.  Information security personnel need to work with their organization’s Loss Prevention personnel to identify those issues and then write them up so that all employees can act to prevent becoming victims.

Those of you closet box checkers need to give it up.  You are doing your organizations a huge disservice because you are not advancing information security; you are advancing a check in a box.

Advertisement

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.  Visa in Canada also requires 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.

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.

Merchant Levels

I get requests all of the time regarding how to determine an organization’s merchant level.  Even though the card brand Web sites have this information posted, the questions still persist.  But even with those tables and references such as this post, it is very important for all merchants to remember that the only entities that can definitively set a merchant’s level are the merchant’s processor(s), acquiring bank(s) or the card brands.

So, while what I am going to discuss in this post should provide the information necessary for most merchants to determine their merchant level, you cannot use this post as the definitive answer on this subject.  This is only my opinion.  Again, if you want a definitive answer, you need to get that from your processor(s), acquiring bank(s) or card brand(s).  Also, before I forget, I have not included a discussion regarding vulnerability scanning, penetration testing and other requirements, so you will need to reference the card brand tables for those other requirements.

One would think that this issue is simple to resolve.  After all, the card brands have this information posted on their Web sites.  So, you just go to their Web sites and figure it out.  Oh, if it were only that simple.

Card Brand Merchant Level Tables

The first problem most merchants run into is that Visa, MasterCard, Discover, American Express and JCB all have tables for merchant levels.  Which leads to the first question merchants typically have; “Whose table should I use?”

The answer is you use the tables for only those card brands for which you have a merchant agreement.  This sounds easy enough, but as we will see later on, might not be as simple as you might think.

Things can get even easier for some merchants.  While Visa, MasterCard and Discover have their own table of merchant levels, if you compare them, you will note that Visa, MasterCard and Discover have gotten together and decided to use the same criteria for determining merchant levels.  So, if the only credit cards you accept as a merchant are Visa, MasterCard and/or Discover, you only need to reference the Visa tables as their merchant level criteria are all the same.  But for those merchants that accept American Express and/or JCB in addition to the other card brands, do not fret.  The card brands have made things easy for you as well.  If you are a given merchant level for any other card brand, you are that merchant level for every card brand.  However, as we discuss the merchant level criteria, for merchants accepting American Express or JCB credit cards, smaller processing volumes of those cards can easily make you a Level 1 or 2 merchant.

With the exception of Merchant Level 3, transaction volumes are the total number of credit card transactions processed, regardless of whether those transactions are card present, card not present, e-Commerce, whatever.  Level 3 merchants introduces the concept of e-commerce only transactions, but we will discuss this a bit later.

The Big, Bad, Ugly Level 1 Merchant

Level 1 merchants are the easiest to define and the ones that must go through the full Security Assessment Procedures and produce a Report On Compliance (ROC).  If you are a merchant that meets any of the following annual transaction processing volumes, you are a Level 1 merchant to all of the card brands:

• Over six million Visa, MasterCard or Discover transactions
• Two and a half million or more American Express transactions
• Over one million JCB transactions

The first thing merchants that have big transaction volumes with American Express or JCB is that they can easily end up a Level 1 merchant with very few Visa, MasterCard or Discover transactions.

I Am A Level 2 Merchant, I Can Do A Self-Assessment Questionnaire

On the face of things, Level 2 merchants are also easy to define.  If your organization meets any of the following annual transaction processing volumes, you are a Level 2 merchant to all of the card brands.

• One to six million Visa, MasterCard or Discover transactions
• 50,000 to two and a half million American Express transactions
• Less than one million JCB transactions

Where things get complicated for merchants is in regards to the credit cards they have agreed to accept, particularly JCB cards.  It turns out that if you have agreed to accept Discover or Diners Club cards, you may also have inadvertently agreed to accept JCB cards.  In the United States and some of Europe, Discover processes Diners Club and JCB transactions and your merchant agreement with Discover may have included JCB.  Overseas, JCB processes for Discover and Diners Club in some countries.  As a result, you will need to review your merchant agreement with your processor to make sure that JCB cards are not included in your agreement.  If your merchant agreement does cover JCB cards, even if you have never processed a JCB transaction (mathematically zero is less than one million), technically you could be classified as a Level 2 merchant by your processor or acquiring bank.

For merchants that accept MasterCard, and that would be most merchants, things get further complicated regarding what you need to do for reporting.  A few years ago, MasterCard tried to get Level 2 merchants to do a ROC for compliance instead of an SAQ.  Thankfully after a lot of complaints, that requirement died a quick death.  However, as of June 30, 2012, MasterCard is requiring their Level 2 merchants to:

• Use an internal person certified as an Internal Security Assessor (ISA) by the PCI SSC to create their Self Assessment Questionnaire (SAQ); or
• Use a Qualified Security Assessor (QSA) conduct the PCI Security Assessment Procedures (SAP) and file a ROC.

So those of you Level 2 merchants that were looking forward to only doing an SAQ, you might want to clear that with your processor first.

And remember, if you are classified as a Level 2 merchant by one card brand, you are that level for all other card brands.  So, if you get caught in the JCB conundrum I described above, you will be a Level 2 merchant to MasterCard and you may have to do a ROC.

What Is A Level 3 Merchant Exactly?

At Level 3, things get a bit more complicated, mostly because at this point some of the card brands do not even have a Level 3 classification.  However, as I stated with Level 2, if you have JCB cards being processed, you will end up as a Level 2 merchant regardless,

Where Level 3 really confuses people seems to be the fact that the criteria now focuses on one particular type of sales delivery method, e-commerce.  If your organization meets any of the following criteria, you are a Level 3 merchant.

• 20,000 to one million Visa e-commerce transactions annually
• 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually
• 20,000 to one million Discover card-not-present only transactions annually
• Less than 50,000 American Express transactions

An additional trick with the Level 3 merchant classification is related to the e-commerce sales channel.  According to Visa, MasterCard and Discover, if your organization has 20,000 to one million e-commerce transactions, you can also have less than one million transactions through other sales channels such as physical stores, mail orders and telephone orders and still be a Level 3 merchant even though your total number of transactions technically exceeds one million transactions and is less than two million in total.

As with Level 2, if you are a Level 3 merchant for one card brand, you are a Level 3 merchant for all card brands.

Level 4, I Can Do Nothing

Level 4 merchants process less than 20,000 Visa e-commerce transactions annually and/or process up to 1 million transactions annually.  As with the other merchant levels, if you are classified as a Level 4 merchant, you are a level 4 merchant for all card brands.

As a Level 4 merchant, you are only recommended to attest to your organization’s PCI compliance.  This means that filing an SAQ with your processor or acquiring bank is not required by the card brands.  However, as I posted earlier, some processors are not only requiring that Level 4 merchants file an SAQ, they also require that a QSA sign off on your SAQ.  If you are a Level 4 merchant in Canada, Visa Canada is also requiring that a Level 4 merchant’s SAQ is signed off by a QSA. (As of October 2010, a QSA does not need to sign off on a Level 4 merchant’s SAQ.)

Clear as mud, right?  Well, there are some other issues that need to be considered before you can claim you are a particular merchant level.

Holding Companies And Legal Entities

What can bring the first twist into the merchant level setting process is how your organization is legally incorporated or structured.  If your organization is a holding company with multiple legal entities underneath it, then your multiple legal entities will have their own individual merchant level and require an individual PCI compliance report filing.  A good example of this is Yum! Brands and their A&W, Long John Silver’s, Pizza Hut, KFC and Taco Bell restaurants.  The restaurants are separate legal entities and therefore have their own merchant level and their own PCI ROC.

Sometimes you can negotiate with your processor or acquiring bank to get your multiple legal entities treated as a single entity and do one compliance filing, but they are not obligated to go along with this request.  The key is that you need to negotiate this change before you start your PCI compliance efforts, not after the fact.

Another fact that can complicate this holding company relationship is how the organization processes their transactions.  In some organizations, the individual entities all process their transactions separately under their own merchant numbers and even possibly with their own processor(s) and/or acquiring bank(s).  In other instances, the holding company aggregates transactions from all of the entities, but the transactions are still processed under individual merchant numbers and my be processed through different processors.  And in a third variation, the holding company aggregates the transactions and processes everything under one merchant number.  In the first two instances, typically each entity is going to be responsible for their individual PCI compliance and will report separately.  In the last instance, the holding company is usually held responsible for each entity’s PCI compliance.  However, any determination of what is correct is going to be up to the acquiring bank(s).

And one other thing that comes up regarding holding companies.  There are organizations that attempt to use their legal incorporation as a way to manipulate the level setting process.  They also have each legal entity process transactions through different processors so that their transactions volumes are not known between the processors.  While in the past this was a good strategy to keep your organization creating SAQs, processors have gotten wise to this game and are talking to one another as well as documenting the processors used in the reports.  So for those of you playing this game, it is only a matter of time before you will be found out and possibly have your merchant level changed.

Been Breached?

Take a close look at your merchant agreement regarding PCI compliance.  There should be a statement that says if you suffer a breach, your organization will automatically be classified as a Level 1 merchant for PCI compliance purposes, regardless of transaction volume.  All of the card brands added this to their merchant agreements a number of years ago.

Unless you are already a level 1 merchant, just the thought of not being able to file a SAQ should put the fear of God in you.  Conducting a full ROC, even for a small organization, will likely be extremely daunting and expensive.  So there is added incentive for you level 2 through 4 merchants to make sure that they truly are PCI compliant.

So that is merchant levels.  I hope this gives you the guidance you seek.  It definitely should give you the background you need to discuss the topic intelligently with your processors and acquiring banks.

UPDATE: I ran into a person from Yum! Brands at the 2011 PCI Community Meeting and they informed me that they file one ROC for all of their restaurant brands, however, technically they could file separately for each, but they do not.  I was only using them as an example and apologize for misrepresenting their filing status.

PCI Compliance Scam? You Tell Me

I ran into a situation recently and wanted to voice my disgust over it.

I have a friend that runs a side business with their spouse and, of course, takes credit cards for payment.  They signed up with a processor and obtained a logon to the processor’s Web site for processing card transactions.  A couple of months ago, he called me because he had gotten a letter from his processor saying that they needed to be PCI compliant.  He called me to find out exactly what PCI compliant meant.  So, I listened to how his business operated and told him to fill out and file an SAQ A with the processor since the processor gave them no guidance.

They filed the SAQ A with the processor and then got a call from the processor asking for certification of the SAQ by a QSA.  The processor explained that if they did not have a QSA, the processor would charge them $185 to have a QSA certify their SAQ.  So, I get a second call from my friend asking about this latest twist of events.  I explained to them that having a QSA review and certify an SAQ is not a PCI requirement.  As a matter of fact, the filing of an SAQ by a Level 4 merchant is recommended, but not required by the card brands.

So, now I have a call with this card processor who is demanding that my friend pay them $185 to obtain a certificate from a QSAC certifying that he is PCI compliant.  I speak with a customer service supervisor who explains to me that their company requires that all merchants they process are required to work with one of their recommended QSACs or any QSAC of their choosing.

I asked them to direct me to the PCI DSS or any PCI requirement that requires a QSAC to sign off on a Level 4 merchant’s SAQ.  The supervisor stated that there was no PCI SSC requirement for this; it was their Firm’s requirement.  They then listed off a number of recognized QSACs that could provide such a certificate for my friend.  I was shocked at the number of big QSACs that this person listed off and was surprised that some of these QSACs would be willing partners in this organization’s PCI compliance program.  Unfortunately, a couple of the QSACs this person named did not surprise me as I have always questioned their motives in the PCI compliance arena.

When I asked the supervisor if I could provide a PCI Attestation Of Compliance (AOC) as my friend’s proof of compliance with the PCI DSS, I was told that an AOC was not acceptable and that as an QSAC, my firm would be required to provide a certificate.  When I asked what the certificate would look like, I got an indignant answer that as a QSAC; I would already have that information.  I found this extremely interesting, since no such “certificate” has ever been defined by the PCI SSC.  And near as I can tell, these “certificates” would not be worth the paper they are printed on.  And if shown to any of the card brands, would likely be laughed at as “proof” of anyone’s’ “compliance” with the PCI standards.

Needless to say, this conversation did not go well nor did it last much longer.

But this conversation brings up an issue with the PCI compliance program that has existed from day one.  How do you keep the program relevant to merchants and service providers when you have nonsense like this going on?  These sorts of actions by organizations just add fuel to the fire for critics to use as another argument as to why the PCI compliance programs are pointless and organizations should not bother with complying with any of the PCI standards.

Another problem this situation points out is how uneducated merchants are to the PCI compliance programs and processes.  Even though everything about these programs is documented on the PCI SSC Web site, there are vendors and service providers that abuse their position with these organizations and knowledge of the PCI compliance programs and processes all for their financial benefit.

I have submitted a question to the PCI SSC regarding this situation and hope to have an answer from them in the next few weeks as to whether it is legal or not.  I also intend to bring this situation up at the Community Meeting as well.  In my view, this situation is highly questionable and in my very humble opinion the processor should be forced through some sort of remediation program just like the QSACs face.

Draft PCI DSS v2.0 “Scorecard” Released

It has been a long wait, but the PCI SSC has finally given us a look at the new “scorecard” for v2.0 of the PCI DSS.  For those of you that never knew about the “scorecard,” it was given to QSAs to assess Reports On Compliance (ROCs) to ensure that QSAs have properly conducted PCI assessments.  I have not had a chance to get through all 112 pages of this document, but I have gotten through the first part of it and I wanted to share my thoughts.

The first change to the “scorecard” is its name.  It is no longer the “scorecard,” it is titled ‘ROC Reporting Instructions for PCI DSS v2.0’.  The naming seems to indicate that once the QSA review period is over it will be posted to the PCI SSC’s Web site in the Documents Library.

Overall, the document is similar to the scorecard for v1.2.1, but no longer documents the scores that the PCI SSC QA team will use to assess QSAs.  However, from the way it is written, I would assume that if a requirement in the ROC does not contain everything documented in the Reporting Instructions, that it is considered to have not met the QA requirement.

Another general comment I have is that it is woefully lacking in examples.  While there seems to be a significant amount of guidance provided for what to write in the ROC, there are also ambiguous or unclear references that could be explained if the PCI SSC provided relevant examples of what they desires the QSAs to write.

The biggest change I have found thus far is the removal of the requirement to observe network traffic as the Network Monitoring column is gone from the Reporting Instructions.  Prior to this point, QSAs were required to obtain network traffic via WireShark or similar tool to prove that network traffic is encrypted.  I reviewed requirements 1.2.1.a, 1.2.1.b, 3.2.1, 3.2.2, 3.2.3 and 11.4.a that had the Network Monitoring requirement in the v1.2.1 scorecard.  Based on the training for the 2011 QSA recertification, networking monitoring testing is still something needed for confirming compliance with requirement 1, so even though it has been removed as a column, it appears to still be required.  However, from the Reporting Instructions, the network monitoring is not explicit, so this is one of those areas where the PCI SSC will definitely need to clarify things.

The section in the Executive Summary at the front of the ROC that discusses how a network is segmented to minimize scope will now require a fairly detailed discussion regarding that segmentation.  All network segments need to be described along with their purpose as well as a discussion of how the segments are architected and whether the segments carry cardholder data (CHD).  If access is provided to the cardholder data environment (CDE), that access needs to be described and that description needs to document how access is controlled.  It is very clear from the write up surrounding this section that QSAs and their clients will have to put much more work into this section to satisfy the PCI SSC.

Another clarification area is with the review of system configurations done as part of requirements 1 and 2.  The guidance now given by the PCI SSC is that they no longer want the documentation to be a list of configuration files that were reviewed by the QSA.  However, in the next breath, the Reporting Instructions tell the reader that a QSA must provide enough detail to prove that configuration files were reviewed.  So what is an acceptable level of detail?  Can we say that we reviewed 5 or 25 firewall configuration files?  In the past, we were told that this sort of approach was unacceptable.  The PCI SSC will need to provide one or more examples of language that they will accept.

Of all of the things I have read thus far, the one that just gets me seething is from the “Dos and Don’ts” page.  One of the “Don’ts” is “Don’t copy responses from one Testing Procedure to another.”  Further down on the list is “Don’t cross reference between responses”.  After going through our QA assessment and remediation, we were told by the QA person that we needed to do a better job of putting all of the information from earlier requirements that was relevant into every requirement as each requirement needs to be able to stand on its own.  But now, according to the Reporting Instructions, you cannot bring all of that documentation to the new requirement by using cut and paste.  What a bunch of “make do” work.

But this “make do” work is all because the PCI SSC is basically implying that it cannot trust its QSACs to do the work that is required to ensure an organization is complying with the PCI DSS.  However, just because a QSA writes something in a ROC does not mean they actually did the work.  It just means that the QSA knows how to write what the PCI SSC wants to read.  And to make matters worse, the PCI SSC provides the Reporting Instructions to provide guidance on just what to write as well as telling QSACs to develop ROC templates to speed the writing process.

A prime example of this is a new requirement in the section of the ROC where the QSA documents the list of people interviewed and/or observed.  The PCI SSC now requires the QSA to document what these people were interviewed about or were observed doing.  The purpose of this new requirement is to provide even more “proof” that a QSA did their job.  Another minor example of the PCI SSC trying to get “proof” of a QSA’s work effort is the increase in the level of detail being asked to document is the dates that QSAs were on-site for fieldwork.  In the past, QSAs were only required to document the period covered by the assessment.  However, QSAs are now being required to also document all of the dates of their fieldwork as well as the duration of their fieldwork and review period.

This is one of my biggest issues with the ROC process.  The PCI SSC refuses to adopt a more intelligent and cost effective reporting process of documenting requirement exceptions.  Instead, the PCI SSC requires QSAs to document their fieldwork process in the report.  As a result, an inordinate amount of time, paper and hence money is spent on what is really, in my humble opinion, a totally worthless effort.

I understand why this was required.  When the PCI SSC did not have the right to review a QSA’s work papers and other documentation, having such documentation in the ROC was the only way the PCI SSC, card brands and acquiring banks could assess whether or not a QSA had done their job.  Now that more than a year has gone by since the PCI SSC required all QSACs to include verbiage that allows the PCI SSC to review a QSAC’s work papers, putting all of this effort into a response writing requirement should no longer be required.  QSAs should be able to mark a requirement either ‘In Place’ or ‘Not In Place’.  If a requirement is ‘Not In Place’, then the QSA should document why the requirement is not in place and what the organization is doing to remediate the problem and when the remediation will be complete.  Such an approach would make the creation of the ROC much faster and would make the ROC much quicker to read and easier to understand.  This is the approach used in the accounting industry for their SSAE 16 reports and there is no reason why the PCI SSC could not adopt the same approach.

The PCI SSC continues to cling to this inane reporting requirement because it apparently is relying on the readers of the ROCs to “rat out” those QSACs that are producing inadequate reports.  I hate to be the bearer of bad news, but based on my review of ROCs from other QSACs that I have encountered over the last year, the “bad eggs” are not being weeded out.  Based on my interaction with acquiring banks and various card brands, there are a lot of ROCs that are not being read in detail.  And even those ROCs that are being read, most comments surround anything that is determined to have been ‘Not In Place’.  Occasionally we get a question about an ‘In Place’ item.  Obviously the current approach is not working and as long as the PCI SSC continues this approach, we are not going to build trust between the PCI SSC and QSACs.

I know that this is a dilemma for the PCI SSC, but it is something that needs to be addressed and soon.  Organizations that have to go through the ROC process are pressuring QSAs to reduce costs as much as possible not only due to our current economic conditions but also because of the thin margins retailers live on.  In order to keep the PCI compliance process relevant, the PCI SSC needs to get out in front of this issue.  The PCI DSS assessment process is very labor intensive, so the only cost savings to be obtained will be in making the process less labor intensive.

UPDATE: On the morning of September 20, 2011, the PCI SSC released the final version of the Reporting Instructions along with an FAQ.  These documents can be obtained from the PCI SSC Document Library under the Addition Documents – QSA heading.

QSA Re-Certification – 2011 Edition

It is that time of the year, time for the PCI Guru to take the PCI SSC’s QSA re-certification training and test.  As with last year, the process is all online.

The process started this year with our Key Contact person emailing me the invoice for the training.  Since the PCI SSC is creating individual invoices for each QSA to be trained, our firm is requiring the invoice to be paid by the QSA and then expensed through the firm’s expense reporting system.  Why the PCI SSC cannot just issue a single invoice for a firm and get it over with, I just do not know.  I had to fax the invoice into the PCI SSC with my credit card information.  They make it very clear that they have a secure fax server.  I will say this, I faxed in the invoice on Monday and by Tuesday I had my logon credentials for the training and examination.  So the registration process is very quick.

The PCI SSC appears to have contracted with a new CBT provider that has better capabilities than last year’s provider.  The site is simple but functional and easy to navigate.  I did have some issues with getting the training content to process properly.  From time to time, I would get messages indicating that there was a “bad URL” supplied.  This appeared to be related to timeout issues as I could click again on the content and it would eventually be displayed and played.

The training is broken into four modules.  The first module covers the usual topics related to the PCI SSC, the various PCI standards, card processing and other general topics.  The second module covers an overview of the PA-DSS, roles and responsibilities of the various PCI players, validation requirements and overview of the PCI SSC’s assessor quality management (AQM) program.  The third module is all about the PCI DSS v2.0.  The fourth and final module covers miscellaneous topics such as virtualization, documentation required for Report Of Compliance, cardholder data discovery, scoping the cardholder data environment and compensating controls.  There are quizzes at the end of each module to test how well your retention is on the material covered.  Each quiz is around eight questions and the questions seem to be representative of what is on the examination.  According to the documentation on the Web site, this material takes around six and a half hours to cover.

The examination is comprised of 60 true/false and multiple choice questions.  You are given four hours to complete the examination and, according to the documentation, you can pause the examination any number of times and come back at a later time to complete it.  You only get one chance to go through the examination, so being able to pause it is nice to have available should you get an interruption.  I am not sure whether you can skip questions and come back to them later.  It took me about 45 minutes to go through the test and I had some interruptions.

I liked the new Web site but was frustrated at times that content was not always available.  I am not positive if the problem was at my end or the CBT provider’s.  But since I was on a couple of different networks while I went through the content, I am guessing the problem was with the CBT provider as I got the content availability errors on all of the networks I used.

As with last year, the training slide decks are not available for download.  I just do not understand why the PCI SSC does not make the slides and notes available as one or more PDFs.  Not only would it be useful for offline review, but it would also be nice to have as a reference.  I am guessing that they feel that people who have the training material available longer than others have a better chance at passing the examination.

Of the four modules, module three is probably the best of the lot because of its discussion of the PCI DSS.  Each of the 12 requirements is organized around:

• The general concept of the requirement;
• Understanding the requirement; and
• Assessor recommendations.

The general concept of the requirement is just a re-iteration of what is in the preamble of the requirement as written in the PCI DSS.  The Understanding discussion goes into a more detailed discussion of the various high points of the requirement (i.e., the X.1, X.2, X.3, etc. level).  Not only are these sub-requirements generally discussed, but there is also a discussion about why these sub-requirements are necessary.  These first two items are very useful for training clients about why the PCI DSS process is necessary.

The real value though is with the assessor recommendations.  For the first time, the PCI SSC goes on the record and states, in general terms, what types of observations, interviews and documentation need to be obtained and reviewed by the QSA to ensure the requirements are satisfied.  Based on some of the Reports On Compliance I have seen lately, I think a lot of QSAs are going to find out that what they are currently doing for fieldwork is not acceptable.  This information would also go a long way to helping clients appreciate why a Report On Compliance takes the amount of time and money it takes.

The examination is similar to last year’s re-certification examination – a variety of true/false and multiple choice questions.  The questions appear to be written to focus the QSA on black and white issues and to avoid any nuances.  For example, I had a true/false question that stated, “An application that processes, stores or transmits cardholder data sold to a single merchant by a software company must be PA –DSS certified.”  Now, I know what they are trying to get at with this question and the answer is false.  However, the real answer is not so simple and depends on the software vendor.  If we are talking MICROS as the vendor, there is a high likelihood that the software will be resold to more than just one organization, so the software should go through the PA-DSS certification process.  Regardless of whether or not software is PA-DSS certified, the bottom line is that a QSA is going to be required to assess the application for compliance with the PCI DSS and will have more work effort if the software is not PA-DSS certified.

In the end, the good news, or bad news for some of you, is that I was re-certified to be a QSA for another year.

Update On PCI DSS v2.0 QSA Scorecard

For all of those QSAs out there, we found out from the PCI SSC late last week that the PCI DSS v2.0 scorecard will not be released until the first part of February.  This document was supposed to be released sometime this month, but as usual it has been delayed.  For those of you that are not QSAs, the scorecard is the document that tells QSAs how they are supposed to conduct their fieldwork.  The scorecard tells the QSA whether they need to interview people, review documentation, observe a system setting or configuration, observe a process, action or state, specify sampling or monitor network traffic.  Reading the PCI DSS tests does not necessarily always define when these activities are required, particularly those that require the interviewing of people, so having the scorecard is a necessity in order to properly conduct a PCI DSS assessment.

The scorecard is also the grading scale that the PCI SSC uses to assess QSACs to determine if they need to go into remediation.  Points are assessed by the number of items of each of the aforementioned categories.  If the reports assessed by the PCI SSC do not achieve a score of 75% or greater of the possible points, then a QSA goes into remediation.

UPDATE: Just got an update from the PCI SSC late yesterday, Wednesday, February 16. The scorecard is further delayed and they are “hoping” to have it published in the next few weeks. How they expect QSAs to conduct v2.0 assessments without knowing what they are expected review and observe and who to interview is insane. I am guessing that the scorecard will not be delivered until the end of March at the earliest. The scorecard needs to be published with the standard, not after it.

The 2010 PCI Community Meeting

It is that time of the year.  Time for another get together with the PCI SSC, the card brands, participating organizations and QSAs.  This year’s meetings are in Orlando and Barcelona.  Unfortunately, I am not going to be in attendance due to scheduling conflicts.  Since I will not be able to attend, I thought I would provide a topic for discussion.  I want to get the PCI SSC to repeal their inane Report On Compliance (ROC) report writing standard.  This standard has become onerous and, in the end, has become “make do” work.

To understand this situation, you need a bit of history.  Until last year, the only proof that the PCI SSC and the acquiring banks had to prove a QSA had done their job properly was to read the ROC.  The ROC was required to contain references to all of the documentation, interviews and procedures they had observed to ensure that an organization was complying with the PCI DSS.  As a result, this caused the PCI SSC to develop an extensive grading and scoring spreadsheet that is used to determine if a ROC covers everything it is required to cover.  Each test may have any of the following components.

• Observation;
• Interview;
• Documentation;
• Process/action/state; and
• Network monitoring.

Each of these components may be assessed one to four scoring points depending on the number of occurrences that may be contained in the given test.    A ROC must score better than 75% in possible points to avoid remediation.  But the PCI SSC expects that a ROC should score no lower than 95% of possible points.

The PCI SSC has instructed QSAs that each test in the ROC must be able to stand on its own.  This means that one test is not allowed to reference another test.  As a result, QSAs must replicate of a lot of information throughout the report.  This obviously introduces the potential for errors and omissions in the report as well as making the report unnecessarily long.

To ensure the report writing process is truly questionable, the PCI SSC recommends that QSACs develop pre-written templates so that all of the components get covered for each test.  While a template speeds the report writing process, I would still estimate that the report writing process consumes at least one-third to one-half of a PCI assessment’s budget.  Not only does it take time to write, but it takes a lot of time to proof and to review.

As I stated earlier, last year, the PCI SSC began requiring language in all QSA contracts that grants the PCI SSC the right to examine any QSA’s work papers.  AS a result, one would think that this report writing standard would no longer be needed, but it is still in place.

Because a lot of our clients use hosting services, we get to see a lot of ROCs that have been prepared by other QSAs.  You can really tell those QSAs that have not been through the PCI SSC QA process by the fact that their ROCs are very short and lack detail.  But for those QSAs that have been through the QA process, based on my review of their ROCs, the grading scale seems to have caused QSAs to worry more about how the ROC is written and not necessarily on the actual assessment of the security practices of their client.  A lot of the writing is more about meeting the scoring template and not about the controls.  In some cases, the writing starts you to wonder if the control is really in place.

ROCs can become inordinately long because of the replication of the same information over and over.  During our QA remediation, we were told that the average ROC ran around 180 to 200 pages however I have yet to see one produced by us that is under 250 pages and we seem to average around 350 to 400 pages.  I have heard from some reviewers at acquiring banks that the only worthwhile information in these tomes is anything that is not in place and any compensating controls.  If that is all that is getting read, then what is the point of all of this other information that is being ignored?  The point is that it remains the way that the PCI SSC ensures that QSAs are doing their job.  And as I stated earlier if the writing makes you question if the control is in place, then what is the quality of all of this writing?

Now that the PCI SSC has the right to review a QSA’s work papers, there is no reason to require all of this pointless verbiage in the ROC.  QSAs should be able to have one column for each requirement in the report labeled ‘Status’ and the entry in the column is either ‘In Place’ or ‘Not In Place’.  If something is not in place, then the column next to it, labeled ‘Comments’, should document what is being done to bring a requirement into compliance and when that will occur.

If the PCI SSC is not comfortable with this approach, then maybe they have the wrong organizations as QSACs and they need to get rid of those that cannot conduct the work to professional standards.  This approach works for financial auditors, there is no reason it cannot work here.

Have a good time in Orlando or Barcelona.

Where Do I Find PCI Information?

This is a common question that comes up.  Where do you find all of the information on the PCI standards?

The first place to go looking is at the PCI Security Standards Council (SSC) Web site.  The PCI SSC Web site has a number of resources that you need to check out.  These include:

• The PCI Data Security Standard (DSS), the Self-Assessment Questionnaires (SAQ), Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)
• Frequently Asked Questions (FAQ)
• Information Supplements
• Locate a Qualified Security Assessor (QSA), Qualified Security Assessor Company (QSAC), Payment Application QSAC (PA-QSAC) or an Approved Scanning Vendor (ASV)
• PCI training

The FAQ is where the PCI SSC posts all of the questions and answers about the PCI standards.  Questions can be asked by anyone accessing the Web site.  The answers come from representatives of the card brands with the PCI SSC staff collecting and publishing the card brands’ agreed to responses.  Answers to questions typically take four to six weeks to obtain an answer.  However, it is not unusual for answers to take quite a while.  For example, in the case of securing pre-authorization data, it has been almost four years and we are still waiting for a response which the PCI SSC has promised they will deliver in the coming year.

Information Supplements are white papers written by various authors (usually PCI SSC staff or the card brands) and approved by the PCI SSC and the card brands that discuss a PCI standard requirement in detail to further explain a requirement and explain how a merchant or service provider can meet the requirement.  Informational Supplements that have been published thus far include:

• Skimming Prevention: Best Practices for Merchants
• Wireless Guidelines
• Requirement 6.6 (Application Code Reviews and Application Firewalls)
• Requirement 11.3 (Penetration Testing)

The PCI SSC has indicated that more Information Supplements are going to be issued in the future instead of updates to the standards.

Locating a QSAC, PA-QSAC and ASV is provided by a PDF list for each type.  Individual QSAs can be looked up by their name so that you can confirm they are in fact QSAs.  The PCI SSC recently sent out a clarification in one of their newsletters to QSAs discussing the fact that once a QSA leaves their QSAC; they need to join another QSAC who applies to have them transferred by the PCI SSC to retain their QSA certification.  If they do not join another QSAC, they are no longer allowed to use the QSA designation.  So, it is important to confirm that the people and firms you are talking with are in fact QSAs and QSACs.

If a QSAC is listed as in remediation does not mean that the QSAC and their QSAs cannot continue to perform PCI assessments, this just means that the QSAC was found deficient in meeting the documentation and reporting standards of the PCI SSC.  Even though the PCI SSC issued a well written release on the meaning of remediation, a number of unscrupulous QSAs are telling prospects that because a QSAC is in remediation, it cannot perform PCI assessments.  This is patently false and any QSA that makes such a statement should be reported to the PCI SSC for telling such a falsehood.

Of course the most obvious thing provided by the PCI SSC’s Web site is the standards themselves.  Unfortunately, without the benefit of the PCI SSC’s training program, interpreting the various PCI standards can be difficult, if not impossible.  However, there are a number of independent resources for people to use to get interpretations of the PCI standards.  One that I have actively participated in is the Society of Payment Security Professionals (SPSP) Forum.  There is also the PCI Knowledge Base that has a large contingent of QSAs and other experts that can provide guidance regarding the PCI standards.  There are also forums provided through Yahoo and LinkedIn as well as other similar services, but I am not as well versed in the accuracy of the information provided through those venues so I cannot recommend them.

So the next time you are looking for information regarding PCI, here are some resources you can use.