Thursday, April 7, 2016

2016 PCI Workshop Agenda Announced

The Agenda for the 2016 Treasury Institute for Higher Education PCI DSS Workshop was announced this morning. There are still spaces left if you have not registered. Please join us for this lively and highly informative event specifically programmed for the Higher Education community.

Information on registering is in the right sidebar.

Sunday May 22, 2016

4:00 pm - 6:00 pm - Early Conference Registration

6:00 pm - 7:30 pm - Welcome Reception
Those who arrive early can mingle, meet friends old and new, share challenges and triumphs, plan questions, and generally get ready for the event.

Monday May 23, 2016

Monday Morning Pre-Workshop Events
(included with conference registration)

10:00 am - 1:00 pm - Conference Registration

10:00 am - 10:30 am - PCI Workshop Orientation
Whether you are new to the PCI Workshop or new to PCI in general,this session will give you some insight, tricks of the trade, provide you with resources, and start your PCI workshop out on the right foot.

10:30 am - 12:00 pm - PCI DSS Refresh
An optional and interactive session for attendees who want to refresh their knowledge of the PCI to ensure they get the most out of the workshop.

12:00 pm - 1:00 pm - LUNCH ON YOUR OWN

1:00 pm - 1:15 pm - Workshop Begins & Opening  Remarks

1:15 pm - 2:30 pm - Secret Service
Secret Service Agent Bernard Wilson

2:30 pm - 3:00 pm - Networking Break

3:00 pm - 4:00 pm - BUSINESS TRACK
We're All Imposters - Overcoming Self Doubt to Leave the Workshop a Winner
Preston DuBose - Texas A&M

3:00 pm - 4:00 pm - IT TRACK
How to Monitor Threats to PCI Compliance
Shiva Hullavarad - University of Alaska

4:00 pm - 5:00 pm - BUSINESS TRACK
Organizing an RFP for a QSA, ASV, and/or a Merchant Processor
Campus Guard and Indiana University

4:00 pm - 5:00 pm - IT TRACK
PCI Compliance in Hospitality Management Systems Point of Sale and Hotel Property Management Systems
Joseph Goodman, Virginia Tech

5:00 pm - 6:30 pm - The 90 Minute Networking Hour
Our discussions of PCI and your compliance journey will continue informally. We created a special 90-minute hour so you can join colleagues and our sponsors in a relaxed atmosphere to share experiences, renew old friendships, and make a few new ones. Refreshments will be provided. Afterward, attendees are on their own to enjoy the many restaurants, attractions, and entertainment opportunities nearby.

Tuesday May 24, 2016

8:00 am - 9:00 am - Buffet Breakfast

9:00 am - 10:15 am - Surviving the First 48 Hours of a Breach

10:15 am - 10:45 am - Break

10:45 am -12:00 pm - PCI Compliance - An Auditor View
Tim Marley, Oklahoma University

12:00 pm - 1:00 pm - Lunch

1:00 pm - 2:15 pm - BUSINESS TRACK
What a Processer Needs from a University to Validate Compliance

1:00 pm - 2:15 pm - IT TRACK
QSA Top 10 List of Compliance Misses

2:15 pm - 3:15 pm - BUSINESS TRACK
PCI DSS and Third Party Vendors. A Push-me Pull-me Relationship
Katie Todd, Columbia University

2:15 pm - 3:15 pm - IT TRACK
Protecting Merchant Data: A Live Hack Demonstration
Gary Glover, Security Metrics

3:15 pm - 3:30 pm - Networking Break

3:30 pm - 5:00 pm - PCI DSS QUICK HITS
This session will address multiple PCI topics that can be discussed by the speakers in 10 minutes or less.
PCI Workshop committee

Wednesday May 25, 2016

8:00 am - 9:00 am - Buffet Breakfast

9:00 am - 10:15 am - PCI DSS
The View of a CISO
Tim Ramsay, University of Miami

10:15 am - 10:30 am - Break

10:30 am - 11:30 am - Role Playing the Assessment of a MID
Monica Trippler, Utah State University

10:30 am - 11:30 am - Scope Reducing Ideas
Ruth Harpool, Indiana University and PayPal

11:30 am - 12:30 pm - Lunch

12:30 pm - 1:45 pm - A Story of Collaboration Across Campus Units
Mark Haas, VP Finance & Treasurer, Michigan State University
Rob McCurdy, CISO, Michigan State University

1:45 pm - 2:45 pm - Survey Results and Workshop Conclusion

Thursday, February 18, 2016

Where 4.0 Art Thou, PCI DSS?

In a not completely surprising move yesterday, Troy Leach of the Payment Card Industry Security Standards Council (PCI SSC) announced that there would not be a new, version 4.0 of the PCI Data Security Standard (PCI DSS) released in November of 2016. There will be a version 3.2 of PCI DSS released in the first part of this year.
The PCI SSC posted information on version 3.2 of the PCI DSS on their blog yesterday. As expected, the version of the standard will extend the sunset date for SSL V3 and early versions of TLS from June 30, 2016 to June 30, 2018. But there will be other changes to the standard and it sounds like they are still working out exactly what will be included. As with previous updates, the Council has taken market feedback into consideration, but they also look deeply into the current threat landscape. This includes the results of forensic investigations in current breaches.
Some of the changes may include multi-factor authentication for system administrators from within the cardholder data environment, clarification of guidelines covering the masking of displayed card numbers, and incorporating parts of the Designated Entities Supplemental Validation (DESV) for service providers.
When asked why v3.2 was coming out now instead of the fall, Leach mentioned the SSL remediation change and seemed to confirm that the three-year life cycle of the standard was a thing of the past:
"...the industry recognizes PCI DSS as a mature standard now, which doesn’t require as significant updates as we have seen in the past. Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard."
He also says that these incremental changes will allow the Council to focus more of its time on emerging technologies, which are rapidly changing the ways in which payment cards are accepted.

Thursday, January 14, 2016

Call for Presentations for the 2016 PCI Workshop

Hello Friends and Colleagues in PCI DSS Compliance.

It's that time of year again, the program committee is requesting your input and submissions for presentations at the 2016 Treasury Institute for Higher Education PCI DSS Workshop.

The theme of the 2016 PCI DSS Workshop is
PCI DSS: Working Together; Succeeding Together.

In many schools, PCI oversight is the responsibility of the Treasurer/Finance Office yet much of the deployment and implementation of PCI DSS is a matter best left to the experts in Information Technology and/or the IT Security Office. Successful and sustainable PCI DSS compliance requires the identification and planning of common goals between finance and technology. Achieving and maintaining compliance requires top quality teamwork and documentation between Treasury/Finance (the PCI oversight group), Information Technology, third party service providers, and the individual departments that accept cards.

Where has your school succeeded in closing the distance between Treasury/Finance and Information Technology? What documentation and communication success stories do you have to share? Share your challenges or your glorious successes (or even your dismal failures) in implementing and maintaining PCI DSS compliance in the face of ever changing threats and attacks.

Concurrent Educational Session Topic Ideas

(All sessions should emphasize the collaboration needed between Finance and Technology to succeed.)
  • Dealing with PCI DSS and Changes in Vendor Delivered Technology
  • PCI DSS and Third Party Vendors, a Push-me Pull-me Relationship
  • PCI DSS: Funding the "Unfunded Mandate"
  • PCI DSS Change Management for Finance
  • Innovative Scope Reducing Solutions
  • Learning a new language; "IT meet Treasury, Treasury meet IT"
The sessions are scheduled in one-hour time blocks. Your presentation should be shorter than that in order to allow for Q&A and time for folks to move between sessions that may be in different rooms.

Speakers from Higher Education will be reimbursed for their workshop registration and certain travel, lodging, and meal expenses (maximum one person reimbursed per session). Speakers from outside of Higher Education will receive a complimentary workshop registration.
See General Expense Reimbursement Guidelines for further information.

How Do I Submit a Proposal?

To prepare your proposal, come up with a suggested title, a brief description of your presentation, your school's name, your contact info and suggested co-presenters, if applicable.

Either send your proposal to me using the Contact Form in the right sidebar and I will forward it on, or use that same Contact Form to ask me to send you the Treasury Institute address for Ruth Harpool so that you can contact her directly. (Sorry, to avoid spam I rarely include addresses in this blog.)

The submission deadline is: February 1, 2016

This workshop will be a gathering of your friends and peers, so there is never a hostile audience. You will be welcomed warmly, even if you have never presented anywhere before.  We know that many of you have valuable experiences that we would love to hear about. So get in touch and propose a session for the 2016 PCI Workshop in Savannah, Georgia this May.

Friday, January 8, 2016

Older versions of Internet Explorer expire January 12

What's going on?

Microsoft announced this week that it will be ending its support for older versions of Internet Explorer (IE) on January 12, 2016. What does end of support mean? It means that starting on Tuesday, January 12 (Patch Tuesday), Microsoft will only provide technical support and security updates for the most current version of Internet Explorer available for a "supported" operating system.

The most recent version of IE is version 11, and almost every Windows system should be running that version. There are a few exceptions to this, such as some specialized or older versions of the Windows operating system, like Windows Server or Windows Embedded, which may be used on integrated point-of-sale systems. These exceptions are not able to run Windows 11 at this time. See the lifecycle link below for more information.

Note: All systems in your cardholder data environment must be running the most current versions of their operating systems and software. All patching must be up-to-date. This is required by PCI DSS requirement 6.2.

What is the impact of this announcement?

This means that if you are running an older version of IE on your desktop that you should upgrade to Windows 11 right away. If a new vulnerability is discovered in an older version of IE, that version will not receive a security patch to fix it. And unpatched systems are the primary targets of criminal hackers and malware. Internet Explorer 11 will continue to receive security updates, compatibility fixes, and technical support on Windows 7, Windows 8.1, and Windows 10.

More information

For questions, help, upgrade assistance, and other resources please see the End of Support announcement page at

To learn more about exceptions and other supported operating systems read the Windows lifecycle FAQ sheet at

Wednesday, October 7, 2015

More Observations from the PCI SSC North America Community Meeting

[Our good friend Joe Tinucci also attended the Community Meeting and shares with us his impressions of this year's program. gaw]

I also was privileged to attend the PCI SSC Community Meeting in Vancouver. As with last year's meeting there were several trends that were apparent, both explicitly stated in the sessions and, equally important, discussed at the networking events and on the trade show floor.  Here is a summary of the major trends that I heard at the meeting:

Risk, Risk, Risk

The entire first day of the meeting was devoted to updates from the Council, virtually all of them focusing on risk and risk management.  This theme has carried over from last year, and I assume that it will carry forward to future years.  Using a risk management-based approach it becomes easier for merchants to prioritize what to do first and where to concentrate their scarce resources.  It also makes it easier to incorporate risk avoidance into ordinary business practices.

One major risk that came up repeatedly was third party service providers. It was noted that approximately 1/3 of retail breaches were due to third party vulnerabilities.  Remote access by vendors to merchant systems is particularly problematic; there are standard practices that should be in place to prevent vendors from accessing merchant systems any more often than is strictly necessary.

One excellent resource for managing third parties was the Responsibility Matrix found in the Council's Third-Party Assurance Information Supplement (  Not only does this document provide a framework for assessing the risks of third parties, but also a framework for negotiating the legal responsibilities of each party.  I highly recommend that you download and use this document to help provide the structure for your third party management program.


Another theme was collaboration.  I think it indicates an interest on the part of the Council to expand their purview so as to bring in additional revenues and resources, and to also work with other associations, interest groups, governmental agencies, and rule-making bodies to cooperatively secure payments. Sharing of information, whether officially sanctioned through ISACs or other mechanisms, is one of the few ways that the good guys can stay current with what the bad guys are doing.

Incident Response

There was a lot of discussion of incident response.  The Council recently issued a supplemental guide, Responding to a Data Breach ( that can serve as a checklist or guide to building your incident response program.  The guide's theme of "Preparing for the Worst is the Best Defense" was repeated in multiple presentations.  Prepare now to see more requirements surrounding this area in future versions of the standard.  And, if you haven't yet done so, you should consider holding a "tabletop" incident response exercise just to make sure that you have identified the key players that need to be part of your IR team and that they play well together.


Another recurring theme was segmentation of your cardholder data environment, of course, but also as applied to other environments.  Segmentation is a major scope-reduction tool for PCI DSS compliance.  The newest version of the DSS has an increased emphasis on this topic, particularly validation that your segmentation is working as intended both from inside and outside the network segment.  There was discussion of assurance for your segmentation efforts internal and external vulnerability scans as well as penetration testing to assure that portions of the network that are supposed to be isolated from the rest of the network / Internet truly are isolated and remain that way.  This is one area that will receive even more attention going forward; if not through more requirements then from your QSA / ISAs.

Being Compliant Does NOT Equal Being Secure

Over and over and over, just about every speaker repeated the mantra that being compliant does not mean that you are actually secure.  This is partly to guard against the checklist mentality of compliance, where you do stuff only in order to be able to check the box against the compliance checklist.  But it was also to remind people that we aren't infallible we might be compliant at this particular instant in time but the opportunity to get out of compliance presents itself with the next AV update, new machine added to the network, or vendor software upgrade.  Most of the breached merchants in the last few years considered themselves compliant but apparently not secure.  Hence, the continuing emphasis in the DSS on "Compliance as Business as Usual".  Look for there to be a new direction in future versions of the standard around the associated processes that keep a merchant compliant change management, software upgrades, log creation and review, equipment inspection, and so forth.


It appears that we are finally seeing the emergence of Point-to-Point Encryption (P2PE) solutions for merchants.  This can be another effective way to reduce the scope of your CDE, particularly when used with tokenization.  There are two routes for a vendor to follow when creating a P2PE solution for merchants: validated or unvalidated.  In a validated solution, the vendor integrates validated P2PE applications as components in their larger system, has their solution validated by a QSA specializing in P2PE, and then pays the Council to be listed on the validated solutions website.  (Similarly for validated applications.)  With the upgrade of the P2PE standard to version 2, validated components can now be used by merchants to "roll their own" solution.  One benefit of using a validated P2PE solution, or creating your own system from validated components, is that it makes the merchant independent of their acquiring bank; that is, they can move their merchant account to a different acquirer without junking their P2PE system.

Many acquiring banks have a P2PE solution available to their merchants that may not be listed by the Council as validated, but which is equally well vetted by a P2PE QSA.  The advantage to the acquirer of this route is that their merchants are more closely tied to them and less able to switch acquirers without starting over with another P2PE solution.  The advantage to the merchant is that assuming they do their due diligence with their acquirer to ensure that the offered solution is properly secure and meets their needs the recommended solution may cost less than a validated one and may be more closely integrated with the acquirer.

As noted in Mike's posting, I also was enamored with Vancouver what a lovely city!  Even the weather cooperated to produce picture-perfect days.  The only thing that marred the stay was that I often found myself apologizing (mostly to taxi drivers and waitresses) for being from such a backward country that didn't issue credit cards with chips...  (More on that topic in another posting.)

Joseph D. Tinucci recently moved from the University of Colorado Treasury to Coalfire Systems, Inc., a Colorado-based IT Security Audit and Consulting firm.  At CU Joe managed the PCI DSS compliance program for over 175 merchants across four campuses.  Now he is helping clients manage their compliance programs from the other side of the desk; he notes that it is a refreshing change of pace and duties to be on the "illuminating side"...

Joe can be reached by email to

Monday, October 5, 2015

The 2015 PCI SSC North America Community Meeting

[Mike Leach sent in this terrific summary of his time at the PCI Security Standards Council's North America Community Meeting, held last week in Vancouver, British Columbia, Canada. I wasn't able to attend this year, so thanks Mike! --gaw]

We wrapped up the PCI SSC North American Community Meeting in Vancouver, BC last week. Before I review a few key points of the meeting I want to highlight our host city: Vancouver, BC is a fantastic city! The streets are pedestrian friendly and clean, the people are friendly, the downtown is alive and vibrant after 5. I even stumbled into a shooting set for Minority Report on an evening walk. Then the waterfront and harbor called to us every day, making it hard to go back into meeting sessions. I recommend Vancouver as a vacation destination. I will be back.

This year Indiana University, Michigan State, North Carolina State, Oklahoma State, Penn State and University of the Pacific were represented as well as the British contingent: University of Surrey, University of Manchester and the University of Leicester. If I overlooked any Higher Ed schools I'm sorry we missed you at the meeting.

The theme this year was Educate, Empower, Protect. As a between-standards year much of the content was review and reinforcement of known topics. Building on PCI as Business as Usual the Council reiterated its focus on providing guidance and content for Small and Medium Businesses (Hey, that's us!).

To do that they are using a 4 pronged approach:

  1. Establishing a SMB task force
  2. Highlighting the QIR program
  3. Encouraging us to develop Acquirer relationships
  4. (The Council) Deepening relationships with Merchant Associations
There will also be a refreshed website with a preview offered here:

Another sub-theme was collaboration. We know the bad guys are sharing info and learning as a community. We need to do the same. As IU's Ruth Harpool reminded General Manager for the PCI Security Standards Council, Stephen Orfei, Higher Ed knows collaboration. This is one of our strengths we need to continue to leverage so none of us are left behind. When schools write to the PCI listserv with questions, please offer up your answers or experience. If you don't feel comfortable discussing with the larger group reply privately. Continue to ask and share.

Keynote speaker John Nance related his experiences in aviation and healthcare to information security. Humans are the weakest link. By admitting we will fail we can plan for failure and be ready to respond to failures.  John also supports the call for collaboration. Collaboration without a common goal is just disparate groups trying to cooperate.

Several presentations covered the importance of P2PE and Tokenization. We are starting to see more validated solutions listed. These two services provide real card data security and scope reduction. However in speaking with merchants who have started down this path some acquirers are trying to squeeze all merchants into a category that doesn't fit well. A complete implementation will take some time and planning so start now. Caesars Entertainment reviewed their 3 year project to implement P2PE at all 37 properties in 14 states.

Keynote Brian Krebs highlighted some of his adventures in learning and writing about card markets and ATM skimmers. His prediction for US EMV adoption is that we will see growth in new card/account fraud because so much of our US personal data is out there, unlike other countries with more strict privacy laws or less electronic personal data available.

Those are just some of the highlights. Please see the Council's meeting blog site for more meeting coverage:

Next year's North American meeting will be September 20-22 at the Mirage, Las Vegas, Nevada.
Thank you,
Mike Leach

Mike Leach is a System and Network Security Analyst in the Office of Information Systems at The Pennsylvania State University. As a primary function of that job he has been managing the PCI compliance program for nine years. PSU has successfully bridged the IT-Finance/Treasury gap and in cooperation with the Office of Corporate Controller Mike oversees 55 merchant areas using some 150 merchant IDs across 24 campus locations.

Mike Leach can be reached by using the Contact Form in this site’s sidebar.

Wednesday, June 10, 2015

Designated Entities Supplemental Validation

Who in security doesn't like the idea of making security (and thereby PCI compliance) business as usual, or BAU? The goal of BAU is to enable an entity "to monitor the effectiveness of their security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments." (PCI DSS v3.1, page 13) It's a terrific concept, but it hasn't really taken root yet.

The PCI Council offered some examples of how to implement PCI DSS into BAU activities but they didn't go much further than that in describing what BAU means for an entity subject to PCI DSS compliance. The example suggestions include but are not limited to:
  1. Monitor security controls for effectiveness.
  2. Detect and respond to security failures promptly.
  3. Review proposed CDE changes and follow complete change management practices.
  4. Review compliance impact and PCI scope after organizational changes.
  5. Communicate with personnel and review processes to confirm security controls remain in place.
  6. Review technology at least annually for vendor support and security effectiveness.
They also make a suggestion I think is very important: "Consider implementing separation of duties for security functions so that security and/or audit functions are separated from operational functions."

On June 5, 2015 the PCI Security Standards Council (PCI SSC) took the idea of treating PCI compliance as BAU a step forward. And it's a huge step. They created a new compliance validation program and published the PCI DSS Designated Entities Supplemental Validation For use with PCI DSS v3.1. This document takes a deep dive into the BAU idea and provides a lot more guidance on how to comply in a BAU manner. It digs into the organizational environment and operational processes of the assessed entity.

This new set of validation steps came about because investigations of data breaches revealed an important fact. That is, that too many entities are not maintaining PCI compliance between their annual assessments. If you read the 2015 Verizon PCI Compliance Report you learn that only 28.6% of assessed entities were still compliant less than a year after their assessment. While that's an improvement from a few years ago it's still disappointingly low. But now, if acquirers or card brands want to focus in on mid-year compliance problems with certain designated entities they have a new tool in their belt to help keep these entities in line.

My first reaction on reading this was Yikes! But there are some important things to stop and understand before succumbing to fear. First and foremost, Designated Entities Supplemental Validation (DESV) applies only to designated entities. That designation can only be assigned by an acquirer or card brand. A QSA can't require it during an assessment, and there is no set of self-assessment qualifications that would require you to follow it. It is an additional validation step required for particular entities. The Council provides some examples of which entities it may apply to, which could include:
  • Those storing, processing, and/or transmitting large volumes of cardholder data,
  • Those providing aggregation points for cardholder data, or
  • Those that have suffered significant or repeated breaches of cardholder data.
My take on it is that this would apply mainly to Level 1 merchants and service providers. I can't recall if I have met someone from a university that is a Level 1 merchant. Even with aggregation my school is a Level 2. If an acquirer or a card brand gets suspicious that an entity is not trying to make PCI compliance BAU, the entity may receive the DESV designation.
Secondly, the DESV does not create any new PCI requirements. Instead it tells an entity how they can meet the requirements already included in PCI DSS. It provides a path to demonstrate to their acquirer or card brand that they are maintaining compliance and it is not just an annual checkbox exercise. Each of the DESV requirements refers to the section(s) of the PCI DSS that it comes from.
Here is an example:

DE.1.1 Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
  • Overall accountability for maintaining PCI DSS compliance
  • Defining a charter for a PCI DSS compliance program
  • Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually
PCI DSS Reference: Requirement 12
Each of these requirements also has a detailed testing procedure (often referencing specific documents) and a guidance column, just like you see in the standard itself. You will see things that you don't see in the standard, but those are often considered implicit in the PCI DSS. For example, in DE 1.1 above it references "a charter for a PCI DSS compliance program." This takes requirement 12 up a notch in terms of having tangible evidence that it is being followed.
The additional validation steps are grouped into five main areas to control. Those are:
  • DE.1 Implement a PCI DSS compliance program.
  • DE.2 Document and validate PCI DSS scope.
  • DE.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.
  • DE.4 Control and manage logical access to the cardholder data environment.
  • DE.5 Identify and respond to suspicious events.

There are no surprises here. But I am particularly impressed with Area 2, scoping. It has concrete steps to assess and validate the scope of compliance. We all know how slippery scope can be sometimes. Area 2 sheds a lot of light on scoping here. It covers data discovery tools in some detail and also addresses data exfiltration. I particularly like the requirement to not only document the PCI scope, but also to document what is not in scope. That's thorough.

Some of these new DESV requirements are different from the PCI DSS simply because they go above and beyond in terms of frequency or reporting. For example, penetration testing is required at least annually in the PCI DSS. But in DE 2.4 it becomes a semi-annual process for organizations that use segmentation to limit scope.

I think the DESV program should not be a big concern for colleges and universities at this time. But things do change, and it's a rare day when PCI DSS requirements get looser instead of tighter. Take this example from the FAQ:
  • Q5: Can I use the DESV even if I’m not a Designated Entity?
  • A: Yes. The DESV can be used to complement any entity’s PCI DSS compliance efforts, and all entities are encouraged to follow the DESV as a best practice, even if not required to validate.

I would agree with that. If I had the security resources available to implement DESV now I would do it! However, not many of us in this sector have those kinds of resources. But do take note of the encouragement "to follow the DESV as a best practice." We know that sometimes best practices become requirements later on. Take heed, my friends.

The Designated Entities Supplemental Validation program was released with a good set of supporting documents, including a FAQ sheet, a reporting template, and its own specific Attestation of Compliance. You can read the press release on the PCI Security Standards Council's web site ( and you will find the related documents in the Council's documents library.

Payment Card Industry (PCI) Data Security Standard
PCI DSS Designated Entities Supplemental Validation
For use with PCI DSS v3.1