Monday, November 24, 2014

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;, 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. (

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

Monday, October 20, 2014

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.

Friday, October 17, 2014

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.

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

Friday, October 3, 2014

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

Wednesday, August 27, 2014

Announcing: The 2015 PCI DSS Workshop

PCI DSS Workshop 2015
April 19 - 22, 2015  
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.

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

Tuesday, August 12, 2014

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.


Wednesday, August 6, 2014

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