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.
Posts
No comments:
Post a Comment