Monday, February 16, 2015

SSL is No Longer Strong Cryptography

On Friday the Payment Card Industry Security Standards Council (PCI SSC) released their official statement regarding the acceptability of Secure Sockets Layer (SSL) version 3 for protecting payment data. Based on guidance from NIST and after months of discussions with stakeholders, no version of SSL encryption should be considered "strong cryptography" as defined by the PCI Council.

The Council will be releasing version 3.1 of both the PCI DSS and the PA-DSS to address this issue. The date for the release has not yet been announced.

If you are running any version of SSL on your e-commerce servers, even version 3.0, you should disable it along with older versions of Transport Layer Security (TLS). TLS should be version 1.2 or higher. Most modern and currently patched web servers should support this configuration. If you have old server software this may not be possible.

More information is available in the official statement at this link:

PCI SSC Official Statements:

Friday, February 13, 2015

Stay tuned for a PCI Council Announcement

Information regarding the upcoming release PCI DSS v3.1 and PA-DSS v3.1 is supposed to be coming out today.

Friday, January 23, 2015

Call for Presentations at Our 2015 PCI Workshop

A few of us have been working since late summer to develop a program for the 2015 PCI Workshop presented by the Treasury Institute for Higher Education. As in the last two previous years we are planning on offering general sessions and keynote speakers for the entire group, and also spending some of our time split into two concurrent tracks: Business and Technology. We have been going over feedback and listening to other ideas to make this another great workshop.
But coming up with those ideas is the easy part; we still need to find people who are interested in presenting at the workshop.

So we are turning to you, our friends and colleagues in the Higher Education community who may be interested in doing a presentation on one of these topics, or maybe another topic idea of your own that you would like to share. Here is the list we came up with:

  • Third party/service provider management/oversight
  • Requirement 9.9 and developing programs to manage/track point of interaction (POI) devices and train employees
  • Scoping: What's in, what's out, and why
  • Choosing the correct SAQ
  • Developing campus policies
  • Managing your PCI team
  • Branded campus ID cards and the ramifications for scope, security and risk
  • Incident Response: Policy, documentation, training, testing...
  • Campus security awareness training programs: Developing, managing, and the difference from breach response training 

If you have some experience in any of these areas that you would like to share, please get in touch. Or perhaps some other PCI or payment topic or project you would like to tell us about. Contact info is below.

We are also lining up some terrific industry experts to discuss these topics:

  • EMV, P2PE and Tokenization
  • Managing Merchants, Compliance and Risk from the Acquirer Perspective
  • Penetration Testing, esp. validating segmentation, pen tests vs. vulnerability scans, and tests for new SAQs
If you are interested in taking part in the 2015 PCI Workshop, write to one or more of us on the program committee:

Ron K - CampusGuard
Pete C - 403 Labs/Sikich
Mike L - The Penn State U
Robbyn L U of Arizona
Linda W - Gonzaga U
or Me!

If you don't have contact information for any of these folks, you can leave a message for me by using the Contact Form on the right side of this page.

Thank you in advance for considering sharing your knowledge and experience with us on the Las Vegas frontier this spring. I look forward to hearing from and seeing you all!


Reminder: Outside of invited speakers, the TIHE PCI Workshop is open to members of the Higher Education community only.

Friday, January 9, 2015

Incident Response

[Here is another in our series of  posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. The best practices Joe shares today center on incident response, with which we all need to be concerned. Be prepared and don't think about a breach in terms of "if", but in terms of "when". Thanks for this excellent advice, Joe! --gaw]

Given the continuing publicity surrounding merchant credit card breaches, it is vital that every merchant has a tested Incident Response (IR) plan in place.  Not only is this a requirement of the PCI DSS, but it also makes good business and practical sense.  One of the major benefits of a tested IR plan is the roadmap that it provides when everyone is tempted to panic and run around like chickens with their heads cut off -- believe me, your situation will be difficult enough without some sort of guide or plan in place to deal with the incident and the fallout.

And, the security consensus is starting to gel around the idea that everyone should simply plan on getting breached and so your best defense is to be able to rapidly detect breaches and to move quickly to contain the damage and/or exfiltration of data.  In other words, it is in your future and you might as well be ready for it...

Why Should You Care?

Just about anyone can list a bunch of reasons why you should care about being breached.  But, it would be a good exercise to list as many as possible just in case you need to lay them out for management at some point:
  • Your contract with your acquiring bank requires you to be in compliance with the PCI DSS; being breached is considered prima-facie evidence that you were not in compliance with both your bank contract and the PCI DSS.
  • There are fines assessed by the card associations and by your acquiring bank.  These fines can run to thousands, or hundreds of thousands of dollars.  Someone is going to have to figure out how to pay these unanticipated costs out of their departmental or campus budget.
  • There are investigation and response costs that could easily run into five or more figures.  Just bringing in an outside QSA to perform a Report on Compliance (ROC, also known as the IT Audit From Hell) could be prohibitively costly.  It is likely that the IT budget wasn't set up in expectation of having one (or more) of these audits.  And, like fines, it will have to come unexpectedly out of someone's budget.
  • If there is fraud committed with the stolen cardholder data it is likely that the merchant will have to absorb some or all of the losses.  Given the trends today of issuing banks attempting to transfer liability for fraud directly to merchants, these costs could outweigh all others combined.
  • There will be remediation costs as well as business process changes; the impact of these could be large and could include the cost of new equipment and software and lots of hours of consultant time.
  • There will be the cost of business interruption for the merchant.  Depending on the timing of the incident this cost could have enormous impact, including significant nonfinancial impacts -- imaging not being able to take online admission applications for two weeks before the application deadline.
  • Your ability to accept cards for payments could be restricted or denied.  While this might not be a big deal for some departments, any department doing a significant amount of online business would have to re-implement manual payment processing.  And, completely losing the ability to process cardholder payments could be beyond disastrous for the organization.
  • Finally, your reputation with your customers -- students, staff, parents, the local community, the general public -- will be impacted.  If you screw up in handling the incident the reputational hit could have long lasting effects.

How Do You Know That You Have an Incident?

Studies have shown that most merchants do not detect their own breaches but instead are informed that they have a problem by outside entities such as the card associations, law enforcement, a bank, or through an extortion attempt.  So, in many cases the first sign that you have had a breach comes via a phone call or email.

Another warning sign of an incident is if staff fall prey to any of the many phishing attempts that hit their desk -- if they are trained to report that they fell for it.  Of course, if they don't realize that there is a problem responding to phishing emails or they are too embarrassed to report it, you are back to hoping that you eventually receive the phone call above.

Other signs include "funny" computer or system behavior -- sending out unauthorized emails or files, slow boot times, unexpected or unusual program behavior, changes to file fingerprints, and so forth.

Your staff (and really, any staff members connected anywhere to your network) need to be trained to ask for help when they see these signs so their systems can be investigated and cleaned as quickly as possible.

Before the Incident

There are several key steps that you need to take to prepare for implementing your IR plan:
  • Understand what data is held where in your networks.  This is a data inventory and classification process; everyone says that it is a good idea but not everyone has done it.  At the very least you need to identify where cardholder data is stored and processed so you can designate those PCs/systems as high-risk systems holding critical data.
  • Update / patch all equipment / systems that touch cardholder data.  Most organizations have processes in place for updating their PC operating systems and anti-virus / anti-malware programs, but are there other types of equipment that come in contact with cardholder data that need updating (such as copiers and firewalls)?
  • Identify your primary IR team.  At a minimum, the team should be composed of representatives from Treasury, IT security, Legal, Public Relations / Communications, senior management, the merchant department, and your external IT security vendor (if applicable).
  • Identify your supplemental IR team members, if their expertise becomes necessary.  This will most certainly include someone from your acquiring bank, an IT forensics vendor, local police, the FBI or Secret Service, an outside crisis communications expert, your trusted mailing house, a wholesale credit report provider, your telephone hotline provider, and possibly counselors and advisors to your customers.  Other representatives should be included as the situation requires.
  • Finally, you should draw up the plan and make sure that it gets distributed to all parties holding critical data, their system owners, and their designated staff backups. I have found that a checklist format works well, or you can create it in a "Do this first, then that, then..." format.

IR Plan Components
  1. Immediately contain the data exposure and minimize data loss
  2. Preserve the evidence
    •   Do not access the system
    •   Remove network and web access
  3. Alert all necessary parties immediately
  4. Call for forensics help
  5. Gather the relevant merchant data (merchant ID, merchant contacts, merchant transaction volume, last PCI DSS status, etc.)
  6. Continue with your IR plan
This document can be found at:

There are many step-by-step frameworks for creating an IR plan; find one and customize it for your organization if you have to start from scratch (see resource suggestions below).
During the Incident
First – Clear your calendar for the remainder of the week.  This incident will take an enormous amount of time between phone calls, in-person meetings, working with the incident response team, documenting, and so forth.  Kiss your calendar goodbye!
Second – Notify and assemble the team.  Decide when to bring the acquiring bank into the loop, and then bring them in.  If you consider the acquirer to be your partner, you would bring them in sooner than if you consider them to be an adversary; in any case you will need to let them know eventually.
Third – Contain the damage.  Make sure that everyone involved at the merchant understands that they must:
  • STOP -- do not touch the machine, do not unplug the power
  • ISOLATE -- remove the machine / system from the network by unplugging the network (or Internet) connection
Fourth – Figure out what happened to which system and how to work without it.  Remember that you have a clock ticking -- the getting-back-into-business clock.  While you do not want to do anything in haste, you cannot dawdle...

Fifth – Communicate as appropriate to your constituencies, as directed by the IR team.

Sixth – Remediate.  Fix whatever business processes went wrong, and make sure it doesn't happen again.

After the Incident

Once you are through the mad rush of responding to the incident, you should debrief the IR process.  What did you learn from the incident, as well as the response to the incident?  What weak technical and/or business practices were identified in this process and how can they be fixed and/or strengthened?  While it is easy to skip this step, it will help strengthen your response the next time the IR plan is activated.


There are many incident response-related resources available.  As noted above, the Visa What To Do If Compromised document is a great resource upon which to base a merchant IR plan.  One resource that we have found very helpful is our bank; they shared access to their risk management portal from which we drew several useful IR templates.  Likewise, your organization's risk management department (if you have one) is a good resource if you need to start from scratch to draw up an IR plan, as are any insurance relationships that your organization might have.  Finally, the usual security websites have lots of IR plan templates -- SANS, GIAC, ISACA, REN-ISAC, and so forth.

Good luck and may all your incidents be only tests of the plan…

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, 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