PCI 2.0 is Released, and Here Is What You Should Look At

The PCI Council is releasing PCI v2.0. (Check their website after noon Eastern time today, the 28th; a Summary of Changes document is already there.) As you read the document you will notice version 2 focuses on clarifications and additional guidance rather than adding a lot of new requirements. There are, however, two “Evolving Requirements” together with a number of clarifications that can impact how your school will approach PCI compliance.

Rather than dissecting the entire document (which will probably be done by any number of bloggers, including those on the blogroll to your right), I wanted to give you a personal view of the most important changes together with the implications for PCI compliance on your campus.

Please note that I am basing this post on the preliminary documentation provided to Participating Organizations (i.e., NACUBO) in advance of the Community Meeting in September. While a few bloggers and vendors have been discussing the new requirements, I felt obligated to honor the Council's embargo until PCI 2.0 was officially released.

Last April, I wrote in my weekly StorefrontBacktalk column about what to expect from PCI DSS version 2.0. The new version includes most of the items identified in that column – including the minor prediction that the new version would be called 2.0. (Hooray, one for Walt!)

Here, then, is my very personal list of the top five areas. I also include some additional developments and observations at the end.

Scoping

The first thing you will notice when you open PCI v2.0 is a greatly expanded section telling you that you need to spend some time defining your PCI scope before you start validating your compliance. Version 2 tells you to identify explicitly all the locations and flows of cardholder data annually before they begin their assessment. The specific instructions are to make sure there is no data leakage outside the cardholder data environment (CDE). If you find any you either eliminate the data or include it in the assessment.

The PCI Council stopped short of requiring merchants to use an automated data discovery tool to find all their cardholder data. To me this omission is regrettable even if I can understand their reluctance to endorse any particular technology. Already security-conscious schools use these tools to find those wayward databases that have cardholder data but the IT or business staff don’t know about.

Like I said, from the Council’s perspective not mandating a specific technology makes sense, but they could have mandated a procedure without naming a specific tool (One example is Cornell’s Spider; there is a number of other open source and commercial products available). From a risk perspective it is difficult to see how any campus with multiple merchant IDs and departments can be certain that cardholder data hasn’t leaked into other systems or employee laptops by just asking users whether they store cardholder data or not.

In my perfect world (you know, when I am King of PCI…), I would like to see the Council mandate the use of automated discovery tools. I am convinced that such a move would stop at least some data compromises at Higher Ed institutions by eliminating hidden or unknown stores of cardholder data. But I will take this increased emphasis on thoughtful scoping before the assessment as validation of what I have previously referred to as “PCI Requirement 0.”

Evolving Requirements

While there are no completely new requirements, version 2.0 has two “Evolving Requirements” that are closely related to each other and will have an impact on any school that develops its own payment applications. You should note that each is considered a “best practice” until June 30, 2012 after which they will be required.

Where Requirement 6.2 used to say: “Establish a process to identify newly discovered security vulnerabilities,” the Council has appended: “and assign a risk ranking to newly discovered security vulnerabilities.” Where before your IT staff would review, say, CERT bulletins, they now need to go further and develop their own rankings and take actions based on the school’s own risk assessment. The guidance says: “At minimum, the most critical, highest risk vulnerabilities should be ranked as High.”

The other, related “Evolving Requirement” is a new 6.5.6. This sub-requirement is part of a revamped Requirement 6.5 that in PCI version 2 addresses all software applications, not just web-facing ones as was the case previously. By itself, this clarification (really a change, I’d say) would be worth noting. The new requirement says that if you develop applications you need to avoid or prevent those high-ranking vulnerabilities you identified in 6.2.

The risk in each of these quasi-requirements is that a school is tempted to identify and rank only those vulnerabilities that are really, REALLY scary as “high,” and rank everything else “low.” I hope I’m wrong on that one.

Wireless Security – No More WPA

Sometimes it isn’t what version 2.0 says that is interesting, but what it doesn’t say.

For example, requirement 2.1.1 address wireless security. It was re-subdivided, and it no longer contains any reference to WPA or WPA2. Where it used to say “Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2)”, it now just says you should “Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks.”

That is, the reference to any specific encryption technology has been removed.

To find the reason they eliminated the reference to WPA you have to go to the Summary of Changes document. In my draft copy, the Council says they “removed reference to WPA, as this is no longer considered strong encryption on its own.”

PCI v1.2 eliminated WEP as an option for protecting wireless networks, and since WPA has been regarded as inadequate security for some time it looks like it has been given the PCI boot, too. The two messages for any campus with in-scope wireless networks seem to be either (a) implement WPA2 fast, or (b) rethink whether you really need a wireless network transmitting cardholder data. I’ll also offer some free advice: include any in-scope wireless networks in your risk analysis (Requirement 12.1.2), too.

Hashing

No, I’m not talking about a nice breakfast dish with poached eggs (with or without "salt"...get it?), but an irreversible mathematical function that can render cardholder data out of scope.

Requirement 3.4 provides additional guidance on hashing. The text of the new requirement states that if hashed and truncated versions of the same PAN are present in the cardholder data environment, “additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.” Unfortunately, there is not much information on what those controls should be.

The reason for this revised requirement is that if the bad guys get both a truncated PAN and the hashed version of that same PAN, there are fairly trivial techniques that can be used to reconstruct the PAN. Depending on how you’re using these pieces of data, it may be a significant challenge to separate them and add sufficient “additional controls”. As a QSA, I can only hope that the Council will soon release some formal guidance on what these controls should be. If you use hashing you should continue to look for the same guidance.

By the way, I found it interesting that there is similar advice in Visa’s Tokenization Best Practices. In that document, Visa notes: “If a token is generated as a result of using a hash function, truncated PAN data must not be stored or transmitted in conjunction with the tokenized data.” The message is the same: don’t store hashed values and the associated truncated PANs in the same place.

Rogue Wireless

The clarification to Requirement 11.1 is a sensible one that may make compliance easier for most campuses which, as we all know, have wireless networks like some places have mice.

That requirement deals with wireless security and formerly instructed retailers to “test for the presence of unauthorized wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS.” Those of you who attended the Treasury Institute’s PCI Workshop heard Jeff Hopkins describe how he meets this requirement on Purdue University’s campus. With this clarification you and Jeff may now have some options.

The requirement has been clarified to state that “methods that may be used in the process include, but are not limited to, wireless network scans, physical site inspections, network access control (NAC), or wireless IDS/IPS.” The big change here is the "physical site inspections" bit. That means you don’t necessarily have to walk around campus carrying a wireless analyzer. Good physical observation and warwalking might do the trick. A word to the wise: don’t let this be a throwaway item or think it is less important. Rogue wireless devices are a very real threat, and you should take these (at least) quarterly inspections very seriously.

Now for the other stuff.

Going beyond the changes to the actual PCI DSS, the Council announced a number of initiatives to improve communication with merchants and processors. These include a new website (with special sections for small merchants which should be helpful to many schools), a new Navigating the PCI DSS document, and revised Self-Assessment Questionnaires (SAQs). The Council deserves a lot of credit for these improvements.

I haven't seen anything yet on the SAQs, but I am hoping any revisions will come out soon. There might even be a new SAQ or two if I understood some of the hints at the Community Meeting. I really hope they at least update SAQ C.

At the risk of talking out of turn, there is one area in Requirement 12.8 that I wish had been addressed. As all of you who know me or are my clients recognize, this requirement is a bit of a hobby horse for me.

To give you some background, when Tom Davis and I were at the PCI Community Meeting in Orlando last month, we represented NACUBO (and you, by the way!) at a separate session just for Associations that are Participating Organziations. The other associations represented were some pretty heavyweight organizations including the National Restaurant Association, National Retail Federation, Retail Solutions Providers Associations, Merchant Advisory Group, and the associations representing convenience stores and gas stations.

During that meeting I pointed out that one area the Council still needs to address is Requirement 12.8. I pointed out the lack of symmetry (and unfairness) in 12.8: merchants need to get their service providers to acknowledge in writing their responsibility for the security of the data in their control, but there is no corresponding requirement for the service providers actually to give that acknowledgement! The Council staff and the card brands (all of them) nodded thoughtfully and took notes, so maybe we will see this reflected in an updated version. Let’s all keep our fingers crossed.

There is a lot more, but I wanted to offer my personal view of what I thought were the highlights of PCI 2.0. There is a lot of clarification, and the Council staff have done a good work to pull everything together. Don’t let this blog post be the end of your research. Like I noted above, check out some of the excellent security blogs in my blogroll on the right side of the screen. Doubtless some of these will bring a different set of items to your attention.

I hope everyone reading this continues to support NACUBO and the Treasury Institute for their leadership in helping Higher Ed stay informed on PCI and secure in their processing of payment cards. We'll definitely plan on highlighting the changes in PCI 2.0 at the PCI Workshop in May.

How Does Your Affinity Card Program Stack Up?

Does your school have an affinity card program? If so, you might want to check out how it is doing versus the competition.

In case you missed it, the Federal Reserve Board on Monday released a report that contains payment and account information about more than 1,000 agreements between credit card issuers and higher ed institutions that provide for the issuance of credit cards to students. The Board also launched an online database with additional information such as the terms of these agreements.

You can get the details here. There is an online database, and can access the complete agreement text in PDF format and see the information submitted by card issuers regarding payments and accounts.

The data are only for 2009, but it may be a good indication of how things are going presently.

PCI Compliance Report Published

Verizon recently released a second report "2010 Payment Card Industry Compliance Report." The report compliments its annual data breach investigation report. There is some good reading here. It analyzes findings from actual PCI assessments conducted by Verizon. "The report examines the progress of organizations toward the goal of compliance and includes topics such as how and why some seem to struggle more than others." It also has statistics on which PCI DSS requirements and sub-requirements are most and least often in place (or compensated for) during the assessment process.

One finding that matches my own experience -- and that of many Higher Ed institutions -- is that merchants struggle most with three requirements: Requirement 10 (logging), 11 (testing systems), and 3 (protect stored cardholder data).

There were also two conclusions that give more importance to PCI (and argues against some of the PCI skeptics). First, they found that companies that were breached were 50% less likely to be PCI compliant than the overall population of organizations. Secondly, PCI addressed all of the top 10 threats that lead to data compromises. Indeed, for most of the threats PCI offered multiple layers of defense.

One of my favorite quotes is:

[W]e must further draw a distinction between the terms “compliance” and “validation.” Compliance is a continuous process of adhering to the regulatory standard. Validation, on the other hand, is a point-in-time event. It is a state of nature analysis that attempts to measure and describe the level of adherence to the standard. An organization may be able to pass validation in order to “achieve compliance” but then—once the QSA leaves—become lax about maintaining the degree of security the standard is designed to provide over time. [This means that PCI compliance is an ongoing responsibility - not a one-time event.]

Another quote reinforces the value of getting an outside opinion:

Furthermore, these findings demonstrate the importance of external validation against the standard. Most organizations appear overconfident when assessing the state of their security practices. The data also suggests that a significant proportion of these practices tend to erode over time, and that maintaining an ongoing approach to compliance is critical.

[O]rganizations are better at planning and doing than they are at checking. This is important to understand because checking is a prerequisite to acting. If the check phase is broken, organizations cannot react to events, remediate flaws, or maintain the state of security practices over time. [There is more detail on pages 7 and 8, and yes, I know what you're thinking...what else would you expect from a QSA!?! But the point is valid nevertheless: it can be a good idea to get an outside opinion.]

For more information and maybe a different take, good friend and author Anton Chuvakin also wrote about some of the highlights in his blog (click here). You should check it out.

Either way, download the report and have a read. It may contain some good information for your next PCI training (or budgeting?) session.

PCI Community Meeting Outcomes

The PCI Council held its annual Community Meeting in Orlando September 22-23. Tom Davis of Indiana University and I attended representing NACUBO and, thereby, all of you. Here is a brief summary of what happened and what we learned (with apologies for our being late).

Hopefully everyone knows by now that the DSS has moved to a 3-year lifecycle. That means that version 2.0 which will be released in late October will become effective January 1, 2011 and remain for an expected 3 years. Another implication is that the current version 1.2 will remain in effect until the end of 2011. That means that for the next year, you can renew your validation under either standard.

The Self-Assessment Questionnaire (SAQ) process is the same, but there will be some changes, particularly (I expect) to SAQ C. The changes were not announced, but they should be made public with v 2.0. There also will be a new Navigating the PCI DSS at the same time. This is a particularly valuable document too many people don’t know about, and that’s a shame. It focuses on the intent of the requirements, which, as we all should know, is the key.

The Council will be revamping its website to provide more information for small and medium-sized merchants. This is really good news. We saw screen shots, so we can’t say too much about what will be there, but we can look forward to additional information and resources, which will benefit many Higher Ed institutions.

Importantly, two new white papers are being released. The more relevant is the “Initial Roadmap – Point-to-Point Encryption and PCI DSS Compliance.” The other deals with “PCI DSS Applicability in an EMV Environment” which deals with chip cards. Each document addresses how the technologies can re-shape your PCI scope and, therefore, your PCI compliance effort. In the Council’s words:

Currently no global standardization of point-to-point encryption technology or validation of its implementation exists in the industry. However by providing this new guidance on P2PE, the Council has taken the first step by definitively stating that P2PE may simplify PCI DSS compliance by reducing the scope of the cardholder data environment. In identifying the environments that still require the security protection of the PCI DSS, the guidance determines that P2PE solutions do not eliminate the need to maintain PCI DSS compliance for specific systems. It also recognizes the need for a set of criteria to validate the effectiveness of P2PE solutions so that merchants can have confidence that the solution they deploy properly secures cardholder data, which the Council plans to develop and release in 2011.

There are a number of clarifications to particular PCI requirements, and some with multiple parts have been re-structured into individual sub-sub-sections. Therefore when you see v 2.0, it may look longer or thicker, but there really isn’t too much new or additional.

We also heard reports from the various Special Interest Groups or SIGs. They are still studying Virtualization, Scoping (now broken into three separate working groups: Encryption; Tokenization; Scoping Considerations), Wireless (working on Bluetooth now), and Pre-Authorization Data (think automated gasoline pumps and hotels). My personal favorites – and the ones I’m watching – are two of the Scoping SIG working groups: tokenization and scoping considerations. Hopefully we’ll see reports and recommendations early in 2011.

The schedule for releasing v 2.0 is October 28. Mark that date. Once the revised SAQs are available I’ll be discussing them here with the implications for your campus. Meantime have a look at the white papers if they are of interest. Personally, I’m much more interested in the Tokenization paper coming out in the new year.