Archive for September, 2011

09
Sep
11

More Requirements That Cannot Be Marked ‘Not Applicable’

In the August 2011 issue of the PCI SSC’s Assessor Update, there is an article titled ‘Checking for SAD’, with SAD meaning sensitive authentication data.  In this article, the PCI SSC is telling QSAs that PCI DSS requirements 3.2.1, 3.2.2 and 3.2.3 cannot be marked as ‘Not Applicable’.  These are in addition to PCI DSS requirements 1.2.3 and 11.1 that I earlier wrote about being unable to mark as ‘Not Applicable’.

To refresh everyone’s memory, the PCI DSS requirements in question are as follows.

3.2.1 For a sample of system components, examine data sources, including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored under any circumstance

3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card-verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance

3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored under any circumstance

The rationale being used by the PCI SSC for not allowing these requirements to be not applicable is as follows.

”These requirements are a fundamental part of the Standards and each review must fully account for all Sensitive Authentication Data (SAD) that may enter the assessed environment or application.”

I have been hearing comments from QSAs questioning the relevance of this clarification in outsourced environments or environments totally operated through bank-owned terminals and networks.  My interpretation of why the PCI SSC is clarifying these requirements is to ensure that QSAs are confirming that outsourced environments truly are out of scope.

The QSAs complaining the most seem to be those that conduct assessments in Asia and Australia.  In these parts of the world, the banks own the terminals and operate the networks that the terminals connect.  As a result, cardholder data never comes into contact with the merchant’s systems.

What I am sure concerns the PCI SSC is the fact that the merchant’s POS system can have a serial or USB connection to the bank-owned terminal.  While the serial/USB connection can provide the bank-owned terminals network access and the POS with cardholder data, in Asia and Australia, this connection is for the transfer of the total of the receipt to the terminal from the POS and the passing of the acceptance or decline of the charge from the terminal to the POS.  What I am sure concerns the PCI SSC is, what, if anything, did the QSA do to confirm that the connection only did just that?

However, I can also understand the position some QSAs’ are taking questioning this clarification.  Particularly in those situations where there is no connection between the POS and bank-owned terminal and the terminal’s network, not an uncommon condition in Asia and Australia.  It is in those situations that I would have to say there is a strong argument to allow for a ‘Not Applicable’ with an explanation that the terminal is bank owned and does not connect to the merchant’s network or POS.

Just another topic for discussion at the Community Meeting.

05
Sep
11

It Is Time To Address PCI Compliance Reporting

It is QSA quality assurance assessment season at work.  I found out through our QSAC key contact person that we are being assessed again by the PCI SSC to see if our Reports On Compliance (ROCs) are written correctly.  This is a rather timely topic given the recent news that the PCI SSC revoked the QSAC and PA-QSAC status of an organization.

If the PCI compliance program has a flaw, this is the spot.  In the immortal words of Billy Crystal from his Saturday Night Live skit ‘Fernando’s Hide Away’, “It is better to look good, than to feel good.”  And that is exactly what the Scorecard, now known as the Reporting Instructions basically promote.  I have written about this topic before, but it is time to remind people of how ridiculous this process is to PCI compliance.

To any QSAs that have been through the QA process, it all comes down to having used the correct language in responding to the requirements of the ROC, rather than whether or not you actually assessed the right things.  And to add insult to injury, the PCI SSC advises QSACs to develop a template for the ROC with all the correct language written and proofed to ensure that ROCs are written to the standard the PCI SSC requires.  Technically, this allows a QSA to just fill in the blanks so that the ROC can be correctly filled out.  

Ironically, on August 3, 2011, this may be exactly what happened to Chief Security Officers (CSO) and why they were stripped of their QSAC and PA-QSAC statuses.  CSO may have had the greatest templates for Reports On Compliance (ROC) and Reports On Validation (ROV), but without the supporting documentation, they could have been just filling in the blanks with the right type of information without actually ensuring that the information supported the conclusions of the report.  While the FAQ issued by the PCI SSC does not explicitly state the reason for CSO’s QSAC and PA-QSAC status revocation, it does imply that this was likely the case when it says, “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 …”

It is not like the PCI SSC cannot determine this fact; it is just that they likely do not have the resources to go through a proper assessment of a QSAC or PA-QSAC.  We have been repeatedly told over the years that the whole reason that all of that verbiage is required in the ROCs and ROVs was that the PCI SSC and the acquiring banks only had that language to give them an idea of what was performed, how it was performed and what the results were.  However, the PCI SSC has had the right to review work papers as well as the ROCs and ROVs for over two years now.  And what, exactly, the acquiring banks gleaned from the verbiage in the ROCs are debatable as I rarely ever hear back from any institutions regarding questions.  As a result, in my humble opinion, there is no good reason for all of the verbiage in the ROCs/ROVs.  As long as the PCI SSC has access to any project’s work papers as evidence, there is no reason to document all of the fieldwork in the ROC or ROV.  And to take things to their logical conclusion, unless there are compliance issues for a particular requirement, is there really a need for acquiring banks to get anything more than the AOC?

In the past when I have brought this up, it has been rebuffed by the PCI SSC, card brands and processors because they point out that the ROC and ROV are the only pieces of documentation that proves the QSA or PA-QSA did their job.  Really?  Telling your assessors to have a template and fill in the blanks is better?  Seriously?  This all comes down to an ability to trust the assessors are doing their job.  And if you cannot trust your assessors, then what is the point?  Coupling the QA program with an independent assessment of a QSAC’s/PA-QSAC’s work papers should be more than adequate to determine if the evidence exists and the appropriate work is being performed.

Reviewing work papers is a tough process.  In the public accounting world, we have internal and external reviews of our work.  Internal reviews are typically referred to as inter-office inspections as senior personnel from one office examine another office’s work papers for a sample of engagements to confirm that the work papers support our conclusions and opinions.  External reviews are conducted in a similar fashion, but by another accounting firm.  Inter-office reviews can occur as often as necessary.  External reviews typically occur every three to five years.  While all of this can appear a bit self serving, I can tell you from going through numerous inter-office and external inspections that they are anything but easy and typically bring out a number of areas that require improvement or changes in procedures.  I would highly recommend to the PCI SSC that they consider the self assessment and independent assessment approach for QSACs and PA-QSACs to supplement the existing PCI SSC QA process.

There would be all sorts of winners if we brought sanity to the ROC and ROV.  The first would be the organizations being assessed as they would likely see lower costs for their assessments.  I believe this because in my limited analysis of engagement costs, 30% to 50% of the cost of an assessment seems to be attributable to writing the report to meet the requirements documented in the Reporting Instructions.  QSAs would be able to create ROCs and ROVs much faster as the only times that would require detailed documentation would be any items that are Not In Place.  QSAs would win because they would not have to put forth an inordinate amount of effort generating 200+ page tomes.  Acquiring banks and processors would win because they would not have to read through those 200+ pages figure out if there are issues and where they exist.

I intend to bring this topic up again at the PCI Community Meeting in September.  Hopefully we can fix this problem and bring some rationality to the PCI compliance reporting process.

01
Sep
11

Visa Is Upset

It seems that I ruffled some feathers at Visa Inc. with my post regarding their program to incentivize adoption of EMV in the United States.  Since I irritated another vendor today, I thought why not make the day complete and irritate another vendor?

As a result of my “A Carrot for Chip and PIN” post, I was contacted by Visa’s public relations firm requesting that I correct my post to properly characterize the program.

“My client, Visa Inc., requests a correction to a factual error on your PCI Guru blog: “A Carrot for Chip and PIN” (https://pciguru.wordpress.com/2011/08/13/a-carrot-for-chip-and-pin/).
While the initiative is certainly aimed at promoting the use of EMV chip, it is not aimed at promoting PIN, per se.  Hopefully, the following post on the Visa corporate website will provide clarification, but please feel free to contact me if you have questions: http://blog.visa.com/2011/08/26/pin-largely-unaffected-in-u-s-migration-to-emv-chip-2/
Many thanks in advance for correcting the story!”

As requested, I went and read the Visa blog entry.  This blog entry is regarding the fact that PIN usage was not being affected or required by the new program.  Apparently a major industry media outlet had implied that Visa was pushing for not using PINs which is not the case.  However, if you read my posting, I do not reference anything regarding PIN usage.  As a result, I asked the PR person to clarify what the problem was with the post.

“I guess I’m a bit confused about your request for a correction
EMV is known as “Chip and PIN” everywhere around the world.  My post does not discuss PIN usage only that Visa is promoting “Chip and PIN” as a card format as well as the RFID contactless card.
I’m always willing to make corrections, but is what Visa is requesting is that I not use the terminology “Chip and PIN” and refer to it only as EMV?”

To which, I received the following reply.

“Yes, it would be correct if you just removed the references to PIN. While signature is the most common form of authentication uses with chip around the world, some regions such as the UK have so popularized the term chip and PIN that it has virtually become one word.
So yes, it can correctly be referred to as a move to “EMV chip” or just “chip” if you prefer.
Many thanks!”

At first blush, this seems to be a very petty argument as to why I need to change my blog post.

But whoa!  Signature is the most common form of authentication with EMV cards around the world?  So, what is the point of having EMV if signature verification is still used?  I have always been told that the whole point of EMV was the coupling of the chip technology with the personal identification number (PIN).  The only reason signature is the most common authentication method is because, outside of Europe, Ireland and the UK, no one has the infrastructure on a large enough scale to process EMV with a PIN.  That is the whole reason Visa is trying to push EMV and contactless is to broaden its use.

Basically, from my interpretation of this response, I was accurate in my original post when I stated that Visa thinks that removing the PCI ROC requirement is enough to drive merchants to implement EMV or contactless terminals.  How could that be when it would take most merchants 10, 20 or even more years of ROC cost to equal the cost of replacing terminals?  Just how does an organization justify such an expense?  Particularly since the other card brands have not agreed to support this program.

But the other thing that disturbs me about this response is that Visa is upset with the use of the term Chip and PIN.  Never mind the fact that Visa uses the term Chip and PIN on their own Web sites around the world as a reference to EMV.  As well as the fact that Chip and PIN is essentially being synonymous with EMV.

So I respond to the PR person.

“I have reviewed my post (https://pciguru.wordpress.com/2011/08/13/a-carrot-for-chip-and-pin/) against the post on Visa USA’s Web site (http://blog.visa.com/2011/08/26/pin-largely-unaffected-in-u-s-migration-to-emv-chip-2/) and I fail to see why any correction is necessary.
The post from the Visa blog references the fact the [media outlet] stated that the PIN was being dropped in the move announced in http://usa.visa.com/download/merchants/bulletin-us-adopt-dynamic-authentication-080911.pdf.  The Visa blog post goes on to further clarify and define the fact that PINs will still be used.
My blog post says nothing about the PIN being used or not used.  My blog post is about business reasons why such a program are not going to be a reason for US banks or US merchants to move to EMV.  As I reread my post, other than the fact that I used the term “Chip and PIN” in the title and then as a “aka” reference for EMV in the first paragraph, the remainder of the entry refers to the card by EMV or the dual chip terminal.  As a result, I fail to see the need to make any changes to the post as the post has no relevance to the Visa USA blog post other than they both reference the aforementioned Visa program to promote EMV in the US.
If Visa USA does not like the use of the term “Chip and PIN” then I suggest that Visa USA take that matter up with the UK and Irish banks that created it more than a decade ago.  The fact that EMV and “Chip and PIN” are now synonymous with each other is also an issue that I am not responsible for nor will making any change to my blog entry effect.
If there is anything else I can assist you with, please let me know.”

The PR person responds.

“EMV is not synonymous with chip and PIN. The EMV standard specifies a number of cardholder verification methods including signature, offline PIN, online PIN, and no verification. Also, while you may possibly be most familiar with chip and PIN implementations in the UK and Ireland, in fact the majority of global implementations of EMV chip have been with signature. Citing chip and PIN in the headline implies that every chip transaction would be verified with a PIN (as they are in the UK and Ireland), which in the U.S. is incorrect, and I know you want to avoid factual errors.
Thanks again for your consideration of this request. Please consider me a helpful resource on future security matters in which Visa Inc. may be a good fit for your story.”

While I understand the PR person’s point, let us face facts.  Google Chip and PIN or EMV and the other term comes up in the results.  If that is not the definition of synonymous, I do not know what is.  Visa’s beef with my post really is the implied connotation by using the term ‘Chip and PIN’ in the title that a PIN would be required.  Whereas, all I was trying to do was to provide an easily Google-able term for people interested in EMV since EMV is usually referred to as Chip and PIN.  Such a complaint is laughable if it were not so sad.

Then to bring up offline PIN entry when it has been repeatedly shown to be the biggest reason why EMV and contactless with PIN can result in card present fraud is amazing and just shows the limited knowledge this individual has regarding their client’s products and services.  But to add insult to injury, they then bring up the wonderful fact that EMV and contactless can also be used with no authentication.  Not that I think anyone would actually do this, but it is an option.

However, the issue of not using the PIN along with the chip truly comes through in this response.  In my very humble opinion, the fact that Visa actually believes that pushing EMV without the PIN is just hysterical.  What is the point?  And this response actually confirms that I was correct in what I stated in my original post and is why I wrote the original post in the first place.  Given the current state of affairs, there is no business reason for EMV or contactless if PIN is not part of the equation.

But this incentive program does nothing to address the even larger issue that merchants and banks face which is the one of card not present fraud.  Card not present fraud is growing at a 20% to 35% clip depending on the survey you read from wherever in the world and comprises more than 50% of total card fraud.  If Visa really wanted to make a difference and give merchants and banks a reason to push for EMV and contactless adoption in the United States, they would gather the various stakeholders together in e-Commerce and come up with a common API that would allow EMV and contactless work online.  That would rein in card not present fraud and would truly create a business reason for investing in EMV and contactless capability.

As it is now, EMV and contactless are solutions looking for a problem.




September 2011
M T W T F S S
 1234
567891011
12131415161718
19202122232425
2627282930  

Months