Monday, March 10, 2014

Sneaky!

sneaky guy
I have been thinking about one of the new SAQs, SAQ B-IP (Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage), and wondering about how and where it might fit in to my card processing environment or the environments of other Higher Education operations I know of. I had made a brief survey of it to write an introductory post, First Look at the New SAQs: Evolution, and I planned on digging into its depths as soon as time permitted.

Meanwhile, back at the day job, this morning I was checking on PTS validation status of a product and found an interesting link I hadn't noticed before. And what do you know? In the PCI SSC documents library I noticed that three new documents were published in February and early March covering PTS POI devices and the related approval program. Usually new publications show up on the PCI SSC home page, but not in this case.

I will be taking a look at these documents before I write more on SAQ B-IP.

Monday, March 3, 2014

First Look at the New SAQs: Evolution

[Apologies, I didn't get this published as soon as I hoped I would.]

OK, now where were we? Oh yes, the new Self-Assessment Questionnaire (SAQ) types.

And then we have the new guys: SAQ A-EP and SAQ B-IP. What are these all about? The Council recognizes that payment systems are evolving and they are not nearly as simple as they once were. (Who remembers the first one-size-fits-all SAQ, with 75 total questions?) The new SAQs highlight this idea of evolution in two distinct ways.

Let's start with the cooler one of the two, SAQ B-IP.

SAQ B-IP seems to fit the evolution description to me. Its cover page description says it's for Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage. Uh-what? I think I need to parse this slowly.

First of all, it's for a standalone device. It's IP-connected. This reminds me of SAQ C, but evolved. SAQ C is for "Payment Application Systems Connected to the Internet," and SAQ B-IP is for "PTS Point-of-Interaction (POI) Terminals." This sounds like a card swipe terminal that has evolved into something more advanced. These devices must be validated as PCI PIN Transaction Security (PTS) Point of Interaction (POI) devices.

The PTS is now rolled up with some other hardware requirements into the Point of Interaction (POI) Modular Security Requirements v4.0. Here is an excerpt from that document.

The purpose of this document is to provide vendors with a list of all the security requirements against which their product will be evaluated in order to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) device approval.

Version 3 introduced significant changes in how PCI will be evaluating PIN and non-PIN acceptance POI terminals. PCI no longer maintains three separate security evaluation programs (point-of-sale PIN entry device (PED), encrypting PIN pad (EPP), and unattended payment terminal (UPT)). Instead PCI provides and supports one set of modular requirements, which covers all product options.

To qualify to use SAQ B-IP you must therefore use these more specialized devices, which have passed the PTS program tests, to take your customers' payment card information. There are several other conditions to meet, including isolation from other systems and no connections to computers, mobile phones, tablets, etc. This is very specialized hardware, folks. My guess is that these things cannot be part of a centrally-managed, multi-terminal POS system.

Now, for SAQ A-EP. I think this one is more a matter of playing catch-up, it's an evolution in the interpretation of the standards rather than a new technology. As I mentioned in my previous post, On the Eve of PCI DSS 3.0: Scope Creep, Visa and MasterCard have been itching to tighten down security for certain types of e-commerce environments. We saw this from the PCI Council in the Information Supplement PCI DSS 2.0 eCommerce Guidelines, released in January 2013. And we heard the message in the PCI Scoping session at RSA 2013 from Lauren Holloway and Emma Sutcliffe of the PCI Council. This issue was discussed in the technical sessions with Walt Conway at the 2013 Treasury Institute PCI Workshop. It was laid out clearly for assessors at the 2013 PCI SSC Community Meeting. And it was printed in black and white in PCI DSS v3.0, Scope of PCI Requirements: "web redirection servers" are in scope.

So we all knew this was coming, but we still didn't know exactly what it meant. I kept hearing and seeing this phrase, or something like it, "it is recommended that merchants implement applicable PCI DSS controls as needed to ensure the security of the website." But what exactly were these "applicable PCI DSS controls" they referred to? I think the best answer I got was, "the controls that apply in your particular environment." Well, there's a whole heap o' helpful. But now we have the answer to the "Which controls?" question: Use SAQ A-EP.

I started to read through SAQ A-EP as soon as I saw it on the PCI SSC web site. One of the first things I noticed is that it encompassed all 12 PCI DSS requirements. As a matter of fact, I counted 139 questions. That's more than SAQ C!

Then I looked at the qualifications, contained in the Before You Begin section.

SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

This is just what we are doing at my university. We have a third-party processor that handles processing for us in two different ways. If we want to use their fully-hosted system we can set up a complete store using a web-based management tool. This works very well for campus units that have simple processing needs. They want to sell documents or genetic material, handle conference registrations, soil-sampling services, etc. This type of unit reports compliance with SAQ A, and that won't change. But if the unit has more a complex sales model they may use their own web application or specialized shopping cart on their university server, and then they pass the customer off to a payment processing page hosted by our vendor. This is what SAQ A-EP was designed to cover.

Following from the PCI DSS 2.0 eCommerce Guidelines and PCI DSS v3.0,  both our merchant's systems and our processor's systems can affect the security of card data, so they are now both part of the Cardholder Data Environment. Rather than validate compliance with SAQ D, we can use SAQ A-EP if we validate under PCI DSS v3.0 and if we meet the following nine qualifications:

  • Your company accepts only e-commerce transactions;
  • All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor;
  • Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
  • Your e-commerce website is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate the website from all other systems);
  • If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
  • All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS compliant service provider(s);
  • Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;
  • Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
  • Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
This is a fairly tight set of qualifications, and it raises a question for me. What if we have two separate processing environments, wherein we handle both e-commerce and MOTO (Mail Order/Telephone Order) transactions, and process the MOTO sales using a card-swipe terminal connected to an analog phone line (a SAQ B environment?) The standard answer, from the PCI SSC FAQ 1082, is that if you qualify for more than one SAQ, then you should use the more stringent SAQ to cover both. That is usually the one higher up the alphabet. But SAQ B would not cover it at all for an e-commerce CDE. And SAQ A-EP does not contain all the requirements in SAQ B. So does that mean SAQ D, with a whole bunch of N/A answers, along with documentation explaining why those answers are N/A? That would be a very cumbersome way to validate compliance. FAQ 1082 was last updated March 13, 2009 and it's time for an update. I have submitted this question to the PCI SSC Frequently Asked Questions site to see if they will amend the current FAQ answer for today's more evolved payment environments.

That's it for this post. A future post will look at the content of these new SAQs and how they fit into the PCI DSS v3.0 world.

PCI SSC Releases Version 3.0 Supporting Documents

Over the last several weeks the PCI Security Standards Council (PCI SSC) has released many of the documents that support the new version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS). These documents may be accessed in the Documents Library of the PCI SSC web site, https://www.pcisecuritystandards.org/.

Version 3.0 of the standards certainly is another evolution rather than a revolution. If you start reading version 3.0 you aren't going to be shocked. It does have a different look. The check-boxes are gone since version 3.0 is no longer doing double-duty as the reporting template for the Report on Compliance, or ROC. That space has been filled with content from the Navigating PCI DSS, which will no longer be a separate document. I think that is a great idea, because now I don't have to go back and forth between two lengthy docs to grok all of this deeper PCI DSS meaning. But for a quick overview of what's new in the new standard, I strongly recommend going through the PCI DSS Summary of Changes v2.0 to v3.0. Then you will have a good idea of what to expect when you start reading the standard.

The first of the new supporting documents, and one which is sometimes overlooked, is the Glossary of Terms, Abbreviations, and Acronyms v3, released in January of this year. The Glossary is one of my go-to documents to make sure I don't confuse the common meaning of a term with the exact meaning that applies in the context of PCI compliance. There are additions, changes, and removals as new terms come in to replace some older ones. I'll try to do a write-up on the glossary sometime soon.

In February, it literally rained supporting documents. First we saw a number of documents used by the Assessment community, our QSAs and ISAs. There is a new publication called the ROC Reporting Template for v3.0, which replaces the section Instructions and Content for Report on Compliance in PCI DSS v2.0 and the document ROC Reporting Instructions for PCI DSS v2.0. Other documents used by ISAs and QSAs after completing an onsite assessment and preparing the ROC are the Attestations of Compliance: PCI DSS AOC - Merchants v3.0 and PCI DSS AOC - Service Providers v3.0.

OK, what about us merchants out here? I understand that the assessors need first crack at this material, but we are the folks that need to manage our businesses and keep current with the compliance requirements. Well, last Friday was my day, it was SAQ-apalooza! And this time it was not four, not six, but NINE new Self-Assessment Questionnaires that were released for us to dig into. We still have our four, standard SAQs: A, B, C, and D. SAQ D is now split into two separate versions, one for Merchants and one for Service providers, which eliminates the optional "if you are a service provider blah, blah, blah" questions. The younger kids, SAQ C-VT and SAQ P2PE-HW are decked out in their shiny-new v3.0 formats.

And then we have the new guys: SAQ A-EP and SAQ B-IP. What are these all about? The Council recognizes that payment systems are evolving and not nearly as simple as they once were. (Who remembers the first one-size-fits-all SAQ, with 75 total questions?) The new SAQs highlight this idea of evolution in two distinct ways.

Due to time limits, I will leave discussion of those new SAQs for tomorrow.

PS:Don't forget to sign up for the Treasury Institute's PCI Workshop at the end of April! See the sidebar for information and links.

More things to read:
All of these new documents and more are available in the PCI SSC documents library, https://www.pcisecuritystandards.org/security_standards/documents.php.

PCI DSS v3.0
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Thursday, February 20, 2014

PCI DSS and PA-DSS Now in Nine Languages

WAKEFIELD, Mass., 20 February, 2014 —Today, the PCI Security Standards Council (PCI SSC), an open global forum for the development of payment card security standards, announced that the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS) 3.0 are now available in nine languages. Organizations worldwide can now benefit from increased understanding of PCI Standards in their native language.

PCI DSS and PA-DSS 3.0 were published in November 2013, with updates made based on feedback from the Council’s global constituents and response to market needs. More than 50% of this feedback came from outside of the U.S., emphasizing the Council’s active international membership base. Version 3.0 helps organizations worldwide make payment security part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility.
The PCI SSC website supports translated pages and PCI materials including the new PCI DSS v3.0 and PA-DSS v3.0 in the following languages: Chinese, French, German, Italian, Japanese, Portuguese, Russian and Spanish.

See the full news release here:

https://www.pcisecuritystandards.org/pdfs/14_02_20_PCI_DSS_IN_9_LANGUAGES.pdf

Wednesday, February 19, 2014

Accepting Unsigned Payment Cards

I received this question from one of our departments today regarding card acceptance procedures. I did some research to see if things had changed since I last looked, and thought some of you might find the following useful.

"Would you confirm whether or not PCI or the credit card industry requires a signature on the back of cards? Our current procedure requires that the card be signed and/or another form of ID is presented. While updating our procedures we thought we should confirm this."
 
All payment cards have words like "Not valid unless signed" adjacent to the signature panel on the back of the cards. It means exactly that, regardless of what a customer may have seen somewhere on the Internet or on TeeVee. The signature needs to be on the card even if the customer has written "See ID" on the back of their card. A payment card must be used according to the terms of the issuing bank (who actually owns the card) and the card brands. Those terms tell the customer they must sign the card or it is not valid for purchases.

The merchant is responsible for comparing the signature on the back of the card with the signature on the sales draft. This is a security check required by Visa, MasterCard and the other card brands. If the signatures don't match then call for authorization.

If the card is unsigned then you can ask the customer for government-issued photo ID and have them sign the card in your (the merchant's) presence. Then the purchase may be processed. If the customer refuses to sign the card it may not be accepted. Ask them for another form of payment.

This is addressed in each of the individual card brands' operating procedures. Here are some excerpts from the MasterCard and Visa programs.

MasterCard Rules


See http://www.mastercard.com/us/company/en/whatwedo/merchant_rules.html for MasterCard's merchant documents.

Transaction Processing Rules
See Merchant Acceptance Procedures on pages 3-1 to 3-3.

Unsigned Cards

If a MasterCard Card is presented to a Merchant representative and the Card is not signed, the Merchant representative must:

  1. Obtain an authorization from the Issuer,
  2. Ask the Cardholder to provide identification (but not record the Cardholder identification information); and
  3. Require the Cardholder to sign the Card.
The Merchant must not complete the Transaction if the Cardholder refuses to sign the Card.

Visa


See http://usa.visa.com/merchants/merchant-support/resources/library.jsp for a collection of documents for merchants.

Card Acceptance Guidelines for Visa Merchants
See Cardholder Verification and Identification p.32, 33

Unsigned Cards

While checking card security features, you should also make sure that the card is signed. An unsigned card is considered invalid and should not be accepted. If a customer gives you an unsigned card, the following steps must be taken:
  • Check the cardholder’s ID. Ask the cardholder for some form of official government identification, such as a driver’s license or passport. Where permissible by law, the ID serial number and expiration date should be written on the sales receipt before you complete the transaction.
  • Ask the customer to sign the card. The card should be signed within your full view, and the signature checked against the customer’s signature on the ID. A refusal to sign means the card is still invalid and cannot be accepted. Ask the customer for another signed Visa card.
  • Compare the signature on the card to the signature on the ID.

Please note: According to Visa, requiring a customer to provide a photo ID cannot be used as a condition for accepting payment cards, EXCEPT in the case where the card does not have a signature. Interestingly, this is different for MasterCard.

I strongly recommend reading the documents mentioned above. There many requirements and guidelines besides PCI DSS that merchants must follow. Don't rely on just the short snippets I provided here when updating your payment card handling procedures.
 

Tuesday, February 18, 2014

Program Finalized for 2014 PCI DSS Workshop

The program committee for the Treasury Institute of Higher Education 2014 PCI DSS Workshop has finished its work and it's all ready for you now on the Workshop registration page. Please join us for this annual sharing of information among your colleagues. The theme of the Workshop will be structured to answer your questions regarding the changes to the PCI DSS that are coming as a result of version 3.0 that is effective January 1, 2014. View the agenda by visiting the registration link at the bottom of this post.

And we've moved the venue this year: The Workshop will be held in Chicago at the beautiful Palmer House, right in the heart of the city. The Palmer is truly a gem and you will have all of Chicago right out the front door.

I plan on arriving Sunday to start catching up with old friends and meet some new ones as well. Sunday night is a great time to jump in start connecting with your peers at one of the informal restaurant outings. I can't overstate the importance of the networking that is available at this workshop. This is your chance to not only gather knowledge, but to gain support of your PCI compliance colleagues from all around the US and Canada.

Agenda Items include:
  • Threat Trends, Attack Vectors and What the Verizon Data Breach Investigations Teaches Us
  • Merchant and Service Provider Oversight
  • PCI DSS 3.0: What Higher Education Institutions Need to Know
  • Preparing for and Reacting to a Breach Incident
  • Evolution of Security Culture
Participants will
  • Learn how best to manage PCI compliance at your institution
  • Understand how the PCI Council's Special Interest Groups' recommendations and new QSA Quality Assurance program will affect you
  • Share experiences of other institutions that are working on PCI compliance on their campuses
  • Get your questions answered, including what to expect from the PCI Council in the future
  • Earn up to 18.3 CPE credit

Date and Location:

April 27-30, 2014
Palmer House Hilton | Chicago, IL
Registration Fee is $450.00

Check It Out and Register at  www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html.

Tuesday, January 28, 2014

Today Only, Free Training From the PCI SSC

Sorry, this special offer is now expired.

In support of Data Privacy Day, the PCI Security Standards Council (PCI SSC), an open global forum for the development of payment card security standards, announced it will offer PCI Awareness online training free of charge to those who register today on the PCI SSC website. The offer for free PCI Awareness online training expires after midnight 28 January, 2014 EST.

“The Council applauds the National Cyber Security Alliance’s initiative to raise awareness and encourage global collaboration on data protection, said Bob Russo, general manager, PCI Security Standards Council. “And today, as part of our ongoing commitment to securing payment card data globally, we’re pleased to make PCI Awareness online training available at no charge.”

PCI Awareness training helps companies educate employees who handle cardholder data on the importance of payment security. It is one of a suite of training offerings designed and developed by the Council to build awareness and to train, test, and qualify organizations and individuals to assess and validate adherence to PCI Security Standards.

Again, the offer for free PCI Awareness online training expires after midnight 28 January, 2014 EST. See this page for complete information:

https://www.pcisecuritystandards.org/pdfs/14_01_28_2014_On_Data_Privacy_Day_PCI_SSC_Emphasizes_Committment_To_Securing_Payment_Card_Data_Globally.pdf