PCI DSS Evolution - Best Practices

[Here is another in our series of  posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. The best practices Joe discusses today focus on supplemental guidance published by the PCI Security Standards Council. Thanks for these great reviews, Joe! --gaw]

I mentioned in my last column about the activity at the PCI Security Standards Council's North American Community Meeting that there was a lot of discussion of how the PCI DSS will be evolving. Most of that conversation focused on three areas: continuous compliance, greater assurance, and the adoption of best practices.  In this post, I want to look at the current best practices guidance documents issued by the Council as one way of predicting how the standard will evolve.

 

All of these documents can be found at the PCI SSC website, in the PCI Standards Documents Library; https://www.pcisecuritystandards.org/security_standards/documents.php, under the Fact Sheets & Info Supps tab.

Best Practices for Implementing a Security Awareness Program

This is the most recent document issued by the Council to assist organizations in complying with Requirement 12.6 for a formal security awareness program.  What I find most interesting about this document is how detailed and prescriptive it is - it does a very good job of laying out the specific topics on which staff should be trained at which level of responsibility.  In addition, this guide discusses metrics to measure the effectiveness of the training program.  Finally, it provides a Security Awareness Program Checklist for use in managing your program.  With this much specific guidance, I see how it could easily be integrated into Requirement 12 of a future version of the standard.

PCI DSS V3.0 Best Practices for Maintaining PCI DSS Compliance

This document is intended to present best practices for maintaining PCI DSS compliance AFTER a merchant organization has already successfully achieved compliance.  It appears that almost 90% of compliant organizations fail to maintain their compliance by the time the next self-assessment takes place; this is reason enough to rethink how we approach security (which is the goal of this entire process rather than simple compliance).  In effect, this document serves as a roadmap for making compliance your risk-based, measured, business-as-usual practice rather than a once-a-year event.  Since this is the direction in which the standard appears to be evolving, this document points to future new features such as ownership for coordinating security activities, continuous monitoring of security controls, development of performance metrics, and better risk assessment processes.

- Mobile Payment Acceptance Security Guidelines for Merchants as End-Users v1.1
- Mobile Payment Acceptance Security Guidelines for Developers v1.1

The first of these two Guides provides merchants with best practices for accepting / processing payments on mobile devices; the second does the same for app developers.  While the world of mobile devices is constantly changing, these guides focus on three main objectives that remain true no matter the underlying technology:

• Prevent account data from being intercepted when entered into a mobile device
• Prevent account data from compromise while processed or stored within the mobile device
• Prevent account data from interception upon transmission out of the mobile device

As merchants see more mobile payments (and requests for mobile payment acceptance), expect these best practices to evolve as well as reappear as part of the next generation PCI DSS.

- Skimming Prevention: Overview of Best Practices for Merchants
- Skimming Prevention: Best Practices for Merchants

When the topic of skimming devices comes up, what automatically comes to mind -- at least for me -- is skimmers attached to ATMs or gas pumps.  This guidance covers far more than those two situations, including swipe card terminals and the placement of PIN-stealing cameras, and presents best practices for preventing and detecting tampering of physical equipment.  Many pictures of modified devices and checklists make these guides easy to integrate into your merchant processing practices.

Third-Party Security Assurance

As noted in a previous post, engaging a Third Party Service Provider (TPSP) does not absolve the merchant from being compliant.  Even if all cardholder activities are outsourced, the merchant is responsible for the proper vetting and selection of vendors as well as ensuring that they are compliant.  This guide focuses on due diligence in selecting an TPSP, correlating the services provided by the TPSP to the PCI DSS, written agreements, and monitoring.  This guidance will be particularly useful for those merchants in the SAQ A environment, where payment processing is outsourced to a TPSP but where the merchant is still responsible for being compliant, but it applies to all arrangements where a TPSP is engaged.

ATM Security Guidelines

This guidance is intended for ATM manufacturers, integrators, and deployers.  However, the sections on physical security and prevention of shoulder surfing might be of interest to ATM owners or others who have ATMs in their facilities.

There is one more guidance document still to come as a result of the 2014 Special Interest Groups (SIGs) -- Penetration Testing Guidance.  Of all the requirements of the PCI DSS, this one has been most problematic for our organization to understand and meet because good pen testers are few and far between.  This document should help organizations understand what they need to do, either internally if they have the appropriate skill set or through outsourcing this task to qualified pen testers.

The newest SIGs have been created to address:

- Daily Log Monitoring: Guidance on Effective Daily Log Monitoring, and
- Shared Responsibilities: Guidance on Determining Shared Responsibilities for Entities and Third Party Service Providers

I am looking forward to the output from both of these groups because I think that they address particularly problematic areas in the implementation of the PCI DSS. (https://www.pcisecuritystandards.org/get_involved/special_interest_groups.php)

Finally, there are several guidance documents that originated out of version 2 of the PCI DSS but which are still useful:

• eCommerce Guidelines
• Mobile Payment Acceptance
• Cloud Computing Guidelines
• Risk Assessment Guidelines
• Wireless Guidelines
• Tokenization Guidelines
• Virtualization Guidelines

While there are still numerous areas within version 3 of the PCI DSS that need clarification, the best practices and guidance documents above will help merchants make sense of the intent of the areas addressed and prepare for the evolution from best practices to requirements in future versions of the standard.

---

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. Joe can be reached at (303) 837-2185 or joe.tinucci@cu.edu)

What is a PCI Service Provider? (FAQs)

Working with third parties can be either a joy or a constant source of frustration. Or sometimes a little of both. I frequently come into contact with departments in our university who wish to work with an outside party, but have little understanding of what is involved.

One difficult term is "service provider." It's difficult because it can mean different things to different people. And lately the PCI Security Standards Council has been emphasize that "touching" cardholder data may be a little too narrow a definition. Scope can be extended out to entities that can affect the security of cardholder data without actually touching it.

I tried to come up with a short list of questions and answers that help clarify the issue when we are talking about what I call PCI Service Providers. These are the types of entities that are defined in the Glossary and which we are required to manage per Requirement 12.8. There are other types of service providers I will touch on later.

Note: Parts of this post that are in the color green are examples from one single, particular merchant and are not intended to serve as advice or a recommendation.

What is the official definition of a Service Provider?
From the Payment Card Industry Security Standards Council (PCI SSC) Glossary

Service Provider

• Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).

 

How does a Merchant determine if an entity is a PCI Service Provider?

1. If a third party business entity processes cardholder data on behalf of a Merchant, and the transactions are processed using a Merchant ID (MID) obtained by the Merchant from the Merchant's acquiring bank, that entity is a PCI Service Provider for the Merchant and falls within the Merchant’s scope of PCI DSS compliance.
2. If a third party business entity provides services for, or on behalf of a Merchant, and those services control or could impact the security of cardholder data or of transactions that are processed through the Merchant's MID, that entity is a PCI Service Provider for the Merchant and falls within the Merchant’s scope of PCI DSS compliance.

What are a Merchant's obligations to its acquiring bank in regards to its PCI Service Providers?

1. The Merchant must register all PCI Service Providers with its acquiring bank. 

What are a Merchant's obligations under PCI DSS in regards to its PCI Service Providers?

The Merchant must manage all PCI Service Providers according to PCI DSS Requirement 12.8 and all sub-requirements.

1. The Merchant must verify that all PCI Service Providers are compliant with PCI DSS.
2. A written agreement must be maintained in which the PCI Service Provider acknowledges responsibility for the security of the Merchant’s cardholder data.
• For services provided in 2015, the entity must be assessed under version 3.0 of the PCI DSS, unless the relevant services have been previously assessed under PCI DSS version 2.0 and that assessment is valid during the 2015 service period.
• (My organization's standard for validation is a registered Visa or MasterCard Level 1 Service Provider, validated as compliant for all the services that are covered in the agreement between the PCI Service Provider and the Merchant. Each Merchant must decide its own standard)
3. The Merchant must exercise proper due diligence before engaging a service provider.
4. The Merchant must monitor the PCI compliance of all PCI Service Providers at least annually.
5. The Merchant must maintain information about which PCI DSS requirements are managed by each PCI Service Provider, and which PCI DSS requirements are managed by the Merchant.

What if a business entity that is not a Visa or MasterCard Level 1 Service Provider wishes to work with the Merchant?

1. Each Merchant must decide this question itself, based on its own risk assessment process, following PCI DSS v3, Requirement 12.2.
2. My organization has operated under the following internal guidelines. You should work with your own QSA to determine what is best for your organization.
• Any such business entity must be approved in writing by [the owner of Merchant Services] before doing business with the University. Before such approval is given, the entity must meet the same standard of PCI DSS compliance validation as a Level 1 Service Provider would meet. That is, the submission of a valid and properly signed Attestation of Compliance (AOC) and the executive summary section of the accompanying Report on Compliance (ROC) prepared by a PCI Qualified Security Assessor in good standing with the PCI SSC at the time of the assessment.
• The submission of a PCI Self-Assessment Questionnaire, or SAQ, is not sufficient for validation of compliance for PCI Service Providers.

All Merchants must develop their own policies and procedures for working with third-party Service Providers. There isn't a one-size-fits-all solution. How about you share your approach in the comments section?

 

For additional guidance, please see the PCI SSC Information Supplement on this subject, Third-Party Security Assurance, written by the Third-Party Security Assurance Special Interest Group and published in August 2014 by the PCI Security Standards Council.

 

Unsolicited and Unwelcome Contacts

Good Afternoon!

Over the past several days many people associated with the Treasury Institute for Higher Education have received emails and phone calls from a representative of one side in a long-running labor dispute in Nevada between a labor group and a casino owners group.

These uninvited calls/emails are part of one side's aggressive tactics to force a particular outcome in the dispute at the Green Valley Ranch Resort (our host facility for the upcoming 2015 PCI-DSS Workshop). To all our friends and participants that were disturbed by this outreach, the Treasury Institute sincerely apologizes as well as the Green Valley Ranch Resort.

Please do not respond or engage these representatives, and refer all requests to Professional Development Group II, Inc. (our meeting's planning and organizing company) or the Institute’s Executive Directors.  We will continue to work directly with the resort to ensure that the upcoming workshop is unaffected by these tactics.

Contact:
Jon K. Speare
Executive Director
The Treasury Institute for Higher Education

Report from Orlando

[Here is another in our series of  posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. Thanks for the report, Joe! --gaw]

If you have been around the PCI DSS for any length of time, you know that the standard is developed and maintained by the PCI Security Standards Council (PCI SSC).  Every year the PCI SSC holds a series of Community Meetings around the globe; this year's North American meeting was held in Orlando, FL, on September 9 - 11, 2014.  This meeting serves as a good opportunity to find out what is on the Council's mind regarding current issues and the direction of the PCI DSS, to network with other merchants, and to talk to the payment card brands.

There were several trends and/or important issues apparent at the meeting; a short summary follows.

Evolution of the Payment Card Industry Data Security Standard (PCIDSS)
There was a lot of discussion of the best practice guides and information supplements issued by the Council over the past couple of years to clarify the PCI DSS.  It was clear from the conversations that these best practices will be integrated into the next version of the PCI DSS.  So, if you want to plan for tomorrow’s requirements, look at today’s guidance and best practice documents.

Compliance as Business-As-Usual
It was emphasized repeatedly that real system security cannot come from a once-a-year compliance event but must be integrated on an ongoing basis into a business-as-usual process.  Several speakers noted that ongoing compliance monitoring saves a significant amount of time and money over an annual point-in-time assessment.  It was also pointed out that most of the cardholder data breaches in the past year or two were of compliant entities who had let their security posture degrade, or whose compensating controls for PCI DSS requirements that could not be met directly didn’t adequately compensate for the risks / threats they were intended to counter.

Compensating Controls May Not Be Adequately Compensating
I got the sense from the official and unofficial discussions at the meeting that future guidance will tighten up on the issue of compensating controls.  A compensating control is put in place because an entity cannot meet one or more of the PCI DSS requirements, and is intended to address the risk but with a different approach.  Since many of the breaches of compliant merchants appear to have been at the point of a compensating control, extra attention will be given to the justification for a compensating control, the implementation of the control, the verification that the control is actually meeting the goal of the security control it was intended to replace, and the maintenance of the control.  If you need compensating controls, you need to fully document why, what, how, for how long, and who accepted the risk of not implementing the required control.

Risk Management Approach
If there was a clear theme to the meeting it was that merchants and service providers have to adopt a risk management approach rather than a check-the-box mentality to security, whether for cardholder data or any other sensitive data.  Documented risk assessment, ranking, management, and acceptance processes are crucial to best using limited resources to best advantage.  Also, it was noted that the PCI DSS was moving toward risk-based requirements in future versions.

Scoping is Essential
Reducing the scope of the merchant environment wherever it contains cardholder data is an essential technique for reducing the risk for a merchant; that is, limit the machines and systems that hold sensitive data to the fewest possible to process card transactions.  Written documentation of how and why the scope was determined, how the isolation of the cardholder data environment is accomplished and maintained, and how that isolation was tested is a current best practice and very soon to be a requirement.  This includes documentation of how the merchant determined that the scope of isolation from the rest of the network / infrastructure / environment was verified through penetration testing.  The Council has a much-anticipated workgroup creating penetration testing guidelines; once these are issued institutions will need to quickly bring their security staff up to speed on this security technology / technique.

Web Site Security for Ecommerce Transactions
There is a new emphasis on the security of merchant web sites / web applications that hand over the processing of payment card transactions to a third party service processor.  Multiple recent breaches have been initiated with a compromise of the merchant web site, even though the actual payment was processed by the third party gateway processor.  The newest version of the PCI DSS, version 3.0, splits apart the old assessment used with third party service providers in two – one for completely outsourced situations and the other for any other type of ecommerce web site.

Managing Third Party Service Providers
Many organizations outsource the actual processing of a payment card transaction to a third party service provider.  There was a lot of discussion of best practices in managing these service providers, including the requirement to renegotiate contracts to be much more specific about which party is responsible for each of the PCI DSS requirements. Documentation should be provided for how third party service providers were vetted, how their performance is monitored, and to whom they are providing data from the merchant’s customers and the compliance status of those other parties.

Chipcards Are Coming But Are Not The Complete Answer
Chipcards, or smartcards with an onboard computer processing chip that conforms to the Europay / MasterCard / Visa (EMV) standard, are being issued (slowly) by financial institutions and merchants must be prepared to process them.  The implementation of EMV cards is being spurred by an October 2015 deadline by which liability is switched from the card issuer to the accepting merchant for card-present fraud if the merchant cannot process EMV card transactions, as well as announcements of large retailers that they will be upgrading their equipment to accept EMV transactions (most of the announcements have come after massive breaches, with Target and Home Depot providing some recent examples).  EMV cards provide much better protection against counterfeit plastic but do not provide much additional protection against other types of fraud.  Also, other countries that have adopted the EMV standard for the card networks have seen fraud migrate from card-present transactions to card-not-present and ecommerce transactions.

---

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. Joe can be reached at (303) 837-2185 or joe.tinucci@cu.edu)

Announcing: The 2015 PCI DSS Workshop

PCI DSS Workshop 2015

April 20 - 22, 2015  
(Dates corrected)

Green Valley Ranch Resort, Spa and Casino
Henderson, NV (Las Vegas metro area)

The Treasury Institute for Higher Education is facilitating its annual PCI DSS Workshop. This program is geared toward business, financial, or IT manager responsible for PCI-DSS. The workshop will once again explore the unique PCI compliance challenges facing Higher Education institutions. As well as offer a deeper understanding of PCI, how institutions can achieve and maintain compliance, and the opportunity to make valuable new contacts with peers at other institutions facing the same challenges.

Register Online Today!

Please note that attendance at this program is
limited to representatives from colleges and universities only.

Higher Ed PCI Listserv

If you are a subscriber to the Payment Card Industry Compliance Discussion listserv, please be aware that there will be a change to the list address coming this week. You should see an announcement from the list in your Inbox soon.

You may need to change your anti-spam filters to keep the messages coming without interruption.

--Gene

Who Should Drive PCI DSS Compliance?

[This is our second guest post from Joe Tinucci, Assistant Treasurer of the University of Colorado. --gaw]

Whenever I talk to my colleagues around the country about who in their organization is responsible for managing PCI DSS compliance, I usually get two different answers -- either the technical security side of the organization or the business side.  Of course, the merchant is the responsible entity as far as the acquiring bank or the payment card associations are concerned but when there are multiple merchants in the organization there needs to be someone coordinating / managing the compliance effort.  So, who is in a better position to drive / manage the compliance effort?  (Or, as we say around here, who is responsible for herding the cats?)

There are good arguments for letting the technical security people drive the process:

• They are closer to the actual technology used to process transactions at the merchant level.
• They understand the security techniques used to secure the transactions (blinking lights and all).
• They control the infrastructure through which transactions are processed (network, firewalls, phone lines, PCs, and so forth) -- or they have direct links to the people who control it.
• They understand the techno-speak language in which the PCI DSS / PA-DSS is written, and, in particular, understand the objectives behind each of the standard's requirements.
• PCI DSS compliance is a security thing and that is what they are paid to do.

You can probably add other reasons why PCI DSS compliance belongs on the technical side.

On the other hand, I feel that there are good arguments for making the business side of the house responsible for driving PCI DSS compliance:

• They control the money, including funding for those parts of the security process that might need outsourcing (penetration testing, ASV scans, QSA assistance, and so forth).  And, in the event that remediation is required, they are generally the ones who have to figure out where to find the money, often on an emergency basis.
• They already deal with multiple other compliance regimes in a lot of other areas; that experience can be directly applied to the PCI DSS compliance process.
• The business side of the organization is already doing risk assessments in other areas and so can assist with the critical but non-technical aspects of PCI DSS risk assessments (in areas such as phishing, social engineering, broken processes, etc.).
• They are already managing business risk trade-offs in other areas of the organization (particularly in treasury) and can apply that expertise to PCI DSS compliance -- particularly with respect to accepting risk or implementing compensating controls.
• Treasury, in particular, speaks that really strange language that only bankers speak (ACH? settlement? OFAC? credits and debits?) and they manage the organization's relationship with the Acquiring Bank.  It is really that relationship that is driving the organization’s PCI DSS compliance efforts.  In addition, if a merchant account needs to be cut off, it is the business side that needs to work with the Acquirer to close out the merchant account.
• They understand the larger context of the business and how all the moving parts, including payment acceptance, fit together.
• They understand good business practices and procedures that should be in place in every merchant environment.

It is this last point that really convinces me that the business side (most likely Treasury) should be driving the compliance process.  God bless the technical security staff but they will secure whatever they are asked to secure -- including horrible business practices that should never have been allowed in the first place.

In reality, of course, neither side can have a successful compliance process without the other; it is a complex dance between partners with the goal of making each and every merchant secure through both best business practices and best technical security implementations.

Your thoughts on the issue?

---

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses.  Joe can be reached at (303) 837-2185 or joe.tinucci@cu.edu)

A Few Thoughts on Liability

[This is a guest post from Joe Tinucci, Assistant Treasurer of the University of Colorado. --gaw]

The other day I met with some colleagues of mine from a nearby city which was covered under our joint state-wide governmental entity merchant services contract. They had several questions raised by their legal department about their obligations under the contract.  The main thrust of their questions and our subsequent conversation revolved around their liability, for both merchant activity and PCIDSS compliance, when they had completely outsourced their merchant processing to a third party.

Under the typical merchant services contract, the merchant of record is the responsible party -- for everything, including PCIDSS compliance.  You can try to limit your liability by outsourcing your processing to a compliant third party processor, but in the end they are simply acting as your agent and you still have liability for them.  This seemed to be a surprise to my colleagues, even though they had read the contract.

It is probably a good idea to take a few minutes to review your contract to confirm this issue.  If you read it carefully, you will probably not find much, if any, discussion of third party service providers -- everything is framed in terms of your responsibilities to submit valid transactions, of proper amounts, for legal goods and services, in accordance with the card association rules, and so forth.  In addition, your agreement likely requires you to indemnify the acquirer against any losses or liabilities arising from your service provider's actions or inaction.

You might also want to talk to your bank about being the merchant of record.  In our discussions with our bank, they have always indicated that the "merchant of record" is the responsible entity (as well as their client) for everything, including PCIDSS compliance.  If you are not the merchant of record, though, then it's not your problem -- at least according to our bank.  I'm not sure that is the entire story, however, as it is very possible to take a hit to your reputation even if a third party is the merchant of record but processing transactions for your customers (say, an online event registration site processing registrations for one of your departments).  

As can be inferred from the new SAQ A under version 3.0, even outsourcing everything to a compliant third party processer still requires:

 

• Confirmation of service provider compliance with the PCIDSS, as well as ongoing monitoring of that compliance
• Prohibition of the electronic storage of cardholder data
• Physical security of any cardholder data which may be held on paper
• Destruction of the cardholder data when no longer needed, if retained
• A security policy in place that covers cardholder data security, management of third party service providers, written agreements with service providers, and specification from the service provider about which PCIDSS requirements they manage and which are your responsibility

The conclusion from our discussion and this line of thought -- it is extremely important that you thoroughly investigate any service providers before you trust them to handle your merchant activity.

---

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCIDSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses.  Joe can be reached at (303) 837-2185 or joe.tinucci@cu.edu)

Live from Chicago

Our hotel is nicer than this one.

Hi Folks!

I just wanted to check in from the 2014 Treasury Institute for Higher Education PCI DSS Workshop. I have to say that in my four years of attending this event, this year's program seems outstanding. We have had a number of great guest speakers and member-provided programs that show off the amazing talent and depth of knowledge this group possesses.

One theme that has been coming through this week is that there is no other event like this: a three-day workshop (or conference) focused on educating the attendees about information security and PCI DSS. The closest thing to this that I am aware of is the Community Meeting sponsored by the PCI Security Standards Council itself. And considering that we are not the authors of the standard, the higher education PCI compliance community can take a lot of pride in what we teach and share about our nuts-and-bolts, boots-on-the-ground experiences with trying to apply this standard in the most complex environments in the world.

We have heard for years that the unique environments of our college and university campuses are less like a merchant and more like a city full of diverse (and sometimes unruly) merchants when it comes to working with the PCI DSS. And most of us have far fewer resources to work with than a major retail, hospitality, or healthcare corporation. How do we do it?

Commitment. Teamwork. Knowledge. Communication. Sharing.

We have put into practice here and on our PCI Listserv a true Open Source Community in the classic sense. The private business sector could not duplicate what we do here every spring with our PCI Workshop. Can you imagine business rivals working together to share examples of how they conduct their operations? To encourage and help their competitors find the solutions that would keep them in business? To be open to engaging with their rivals to work together and share their corporate intellectual property and the results of their years-long research projects? It's a stretch for me to think of something like that, but it is what we do here intensely for three days every spring and what we do day-in and day-out on our listserv and in e-mails and phone calls to one another.

You know, we're not the ones who came up with the idea of putting unencrypted credit account data on a magnetic stripe stuck to the back of a piece of plastic. We didn't build the systems that can be used to easily steal that data from computers and networks, and then duplicate the cards in order to steal money from innocent victims. An we're not the ones who said "Oops, we better fix that with these 286 security requirements that we'll make merchants who are already broke prove they can meet, every single day without fail. No prior knowledge of InfoSec required." I know none of you thought up this situation. (Although I often get blamed for it.)

But each day we rise to the challenge of PCI DSS compliance and say, "OK. Bring it on!" I'm really proud of all of us here. For me, you guys make my success in my job possible. You challenge me and make me think of how to solve my problems in whole new ways. I am so grateful that I get to meet with you all every year and soak up your energy and optimism.

Thank you Treasury Institute for Higher Education. Thank you PDG and Katy. Thank you Dennis, Ron, and all of you who came from schools spread out from Florida to Alaska. And thank you, Walt Conway, for bringing everything you had to build this workshop into what is has become. I hope we have been able to honor you, in gratitude for what you gave to us. I hope you are also proud of what we have been able to do here this week. We'll remember you always.

2014 PCI DSS Workshop - Still Open

There are still some remaining spaces left if you want to attend the 2014 Treasury Institute PCI DSS Workshop. Go now to http://www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html for more information and to register today.
We have a terrific lineup of presenters and programs this year, with sixteen program sessions, several of them targeted specifically toward each of our main attendee groups: a Business Track and a Technical Track. Our general sessions include industry experts who will speak on threat analysis, data breach response, PCI DSS v3.0 in Higher Education, and our always popular expert panel. And once again we will gain insights directly from the Council, as Bob Russo, General Manager at PCI Security Standards Council, will be with us to talk about PCI DSS 3.0 and Business as Usual.

So please join us next week in Chicago at the historic Palmer House Hilton if you can. You don't want to miss this one!




The Palmer House Hilton in Chicago, Illinois

Sneaky!

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.

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

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

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

http://www.mastercard.com/us/merchant/pdf/ORME-Entire_Manual.pdf

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

http://usa.visa.com/download/merchants/card-acceptance-guidelines-for-visa-merchants.pdf

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.

 

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

The 2014 Treasury Institute PCI Workshop

A Message From Pete Campbell:

As you may know, we’ve been working behind the scenes to put together a dynamic and educational agenda for the Treasury Institute PCI Workshop to take place this April 28-30 in Chicago (see http://www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html for details and registration).  It’s a tall order but we’re trying to carry on and build on the excellent foundation Walt Conway provided.  As usual there are a variety of topics but we’re trying to have a theme of how PCI DSS 3.0 changes things, looking beyond simple compliance, and solving the difficult security and compliance challenges.

The time has come to solicit presenters from within higher education.  As before the Treasury Institute will cover the conference registration fee and hotel for one speaker from each school who presents.  Please reply back to me (pcampbell@treasuryinstitute.org) directly with any questions or if you have a topic you’d like to suggest.  Things are still a little flexible but at this point we have the following openings (the first two in each track are desired topics; if nobody steps forward then we’ll consider additional topic suggestions):

IT Track

• Point of Sale on your network
• Scoping and your network
• Suggest a topic
• Suggest a topic

Business Track

• Selecting the correct SAQ
• Service Provider Oversight: Contracts, Compliance, etc.
• Suggest a topic
• Suggest a topic

 

Thanks, and I hope to see everyone in Chicago.

Pete Campbell, M.Ed., CISA, PCIP, PCI ISA

Co-Moderator/Co-Chair, PCI Workshop

The Treasury Institute for Higher Education

(479) 575-7353