PCI "Open Mic" Session

The PCI Council held the first of two “open mic” webinars today (Wednesday) for Participating Organizations. Since NACUBO is a Participating Organization, I was able to listen. There were a number of interesting questions (and answers) which I’ll try and summarize.

SAQ C-VT

The first question concerned the new SAQ C-VT for virtual terminals. It was noted that this SAQ is intended for merchants with a single laptop key-entering one transaction at a time. The Council reiterated that these merchants do not need external vulnerability scanning since their laptop is likely to move around and there would not be a static IP address. Also, these merchants are perceived as low risk. What was news was that if a merchant uses a stationary workstation, they would need vulnerability scanning.

A follow-up question picked up on this point, asking whether a merchant using a stationary terminal (not a portable, movable laptop) should instead use the regular SAQ C. Unfortunately the only answer we got was that the merchant needs to “ask your acquirer.” Since most acquirers (even when you find the right person) won’t be very familiar with the new SAQ C-VT, merchants will likely end up using their best judgment or ask their QSA (who quite possibly will be equally baffled). My recommendation for any campus in this situation is to use SAQ C or if you use C-VT get quarterly scanning, too.

Training

There will be a new “PCI Awareness Training” program providing a high level introduction to PCI. This program is in addition to the current ISA and QSA training offered currently. This is a good idea, and reinforces the Treasury Institute’s own program to provide PCI training to a wide audience.

The Council has posted the schedule for the first part of 2011 on its website. If you want to know about future dates, the only advice offered (unfortunately) was to keep checking the PCI COuncil website for updates.

PA-DSS

The Council reinforced that PA-DSS only applies to applications that meet all of the following: (1) store, process, or transmit cardholder data; (2) are used to perform authorization or settlement; and (3) are sold to third parties. That is, back office and other applications are not eligible for PA-DSS validation and should be included in your PCI assessment.

Bob Russo addressed the current backlog of PA-DSS approvals and promised that the turnaround time for approving new applications will be 3-4 weeks in 2011.

Miscellaneous

Bob and his colleagues addressed a number of other topics including:

· The Council has no plans to test or qualify Penetration Testers

· All PCI v2.0 documents are online and available for download

· Special Interest Groups (SIGs) are still looking for members to join

· Yes, Issuers are subject to PCI DSS, and the clarification mainly dealt with their need to retain sensitive authentication data such as security codes and PIN data

· If you use a QSA for an assessment, be sure to complete a QSA feedback form

· The Council will continue to update its Frequently Asked Questions (FAQ) list

There will be a recording of the session on the Council’s website soon. You might want to have a listen.

Have You Got An Extra Few Million Dollars Laying Around?

I am always worried/disturbed when I see reports of data breaches. This particularly the case when it involves a higher education institution. The have been three recently reported: the University of Hawaii (which I previously wrote about here), University of Wisconsin - Madison, and most recently The Ohio State University.

The good news is that at least the last two did not involve any cardholder data. That doesn't make the breaches any less worrying, though. If one kind of data can be exposed, then so can cardholder data. The thing about these most recent breaches is that we are starting to see the serious financial costs involved.

According to this report:

Following the lead of other data breach victims, [the school] is offering a year’s worth of credit protection services, which according to Lynch, will cost the university approximately $4 million.

Add this to the brand damage to any institution and the costs can mount fast.

So I guess my holiday wish (in addition to my other holiday wishes...) is that decision makers everywhere realize that while security and compliance is expensive, lack of security is a whole lot more expensive.

New SAQ C and C-VT

As I noted earlier, the PCI Council has released updated Self-Assessment Questionnaires (SAQs) as part of version 2.0. Of greatest interest to many Higher Ed merchants (and actually a whole lot of merchants!) will be the new SAQ C.

The first thing you should know is that it comes in two flavors: SAQ C and SAQ C-VT for virtual terminal users.

The second thing you should know is that my colleague Kat Valentine has produced an analysis of the two new SAQs. Rather than rehash what she has done so well, let me suggest you surf over to her 403 Labs Blog post (click here) and read her analysis. It is thorough and thoughtful.

As most of you know, SAQ C is notoriously difficult to qualify to use. Things have gotten a bit better, but it still is no cakewalk. The same goes for SAQ C-VT. However, if you do qualify it is a whole lot better than SAQ D.

Have a careful read of Kat's analysis, and take a fresh look at your own situation.

PCI and Logging

In my experience, one of the most challenging areas of PCI DSS compliance is logging. Anyone who is familiar with PCI or with Verizon's 2010 Data Breach Investigations Report knows that daily inspection of your logs is not only required, it is good security.

The problem, of course, is that logging is complicated (see Barbie's "Math class is tough!"...if you dare). Therefore, I suggest that anyone involved in, responsible for, or just interested in logging and PCI, head over to good friend and logging guru Anton Chuvakin's blog (click here) for his analysis of PCI DSS log review procedures.

Many of you will remember Anton from his memorable presentation at last year's PCI Workshop. This time he is in process of putting together a string of blog posts which he describes as:

It was written to be a complete and self-contained guidance document that can be provided to people NOT yet skilled in the sublime art of logging and log analysis (a key requirement for this project – guidance was to be useful to such people) in order to enable them to do the job and then grow their skills. It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation (or without any compliance flavor – of course!)

If you are involved in PCI compliance or just the logging part, I suggest you bookmark Anton's blog (if you haven't already!) and follow along. It promises to be valuable, interesting, and if I know Anton, occasionally hilarious.

New SAQs Released and Revised for PCI 2.0

The PCI Council has posted the SAQs for PCI v2.0 on its website (click here to download them).

I'm still looking at them, and I'll have more to say later. It is interesting that there are now two versions of SAQ C. There is plain, old SAQ C (still checking revisions) and a new SAQ C-VT for virtual terminal users.

The same restriction that made this SAQ so difficult to use in practice is in place for both versions, i.e., the terminal can't be connected to any other locations or systems in your environment. Nevertheless, it may be worth a look.

One BIG change in SAQ C-VT is that there is no vulnerability scanning requirement. That's right -- there is no Requirement 11 at all.

I'll be writing more when I have a chance to look at all the SAQs more carefully, but you may want to take a look yourself in the meantime.

Why PCI 2.0 Says You Need to Search For Sensitive Data

On of the big changes to PCI 2.0 is that you now need to document how you determined your PCI scope. That is, you need to demonstrate that you have located all your cardholder data.

But how are you going to do that?

One way is to go around and ask everybody: "Do you have any payment card data?" Don't forget you also need to specify that includes paper and electronic, and that "electronic" includes databases, flash drives, CDs and DVDs, spreadsheets, etc. Good luck with that approach. Can you really ask every staff and faculty member? Can you rely on the answers?

Alternatively you could use an automated tool that seeks out and finds sensitive numbers like payment cards (and SSNs, too). To my way of thinking, this is the only realistic way to determine if you have found all your cardholder data. The reason is that data have a way of leaking out into all sorts of unexpected places. If you don't believe me, consider the recent unfortunate case at the University of Hawai'i which just announced they lost personal information on 40,000 alumni. This is one of the largest Higher Ed security breaches in recent memory.

Based on the press reports, the personal data "was stored on an unsecured UH computer server by a now-retired UH West Oahu Campus professor researching the achievements of UH students after graduation." Furthermore, the data breach could have been prevented if the university had taken “some fairly simple” data protection measures."

One part that the story got right is when they said “This could have been prevented if the university had a policy of scanning its IT system for records containing personal information like social security numbers,” adding that software programs and information technology experts are available to perform such searches.

The part the story -- or at least the expert quoted therein -- gets wrong is where they say that data discovery programs “are not cheap" and add " that the university has struggled in recent years with severe budget cuts and spending restraints." WRONG! Excellent open source (read: "free") data discovery tools are abundant. Two examples are Cornell Spider or SENF from the University of Texas. All it takes is the good sense to use them. Now at least, PCI DSS v2.0 is making it abundantly clear that you really need to do this.

The data compromise didn't include payment cards, as far as I can tell. Nevertheless it is an example of the type of compromise that you could face when payment cards are kept on a workstation or database in accounting or development or the medical center or athletics or the bookstore or the parking garage or...you pick the department.

The moral of this story: PCI once again has your back. The requirements may seem difficult, but the almost unnatural ability of intelligent and well-meaning people to mishandle sensitive data is a risk you cannot take. Next time, it may not be a professor at a distant institution. It may be someone right on your campus who with the best of intentions abandoned all common sense and put your school in the headlines.

Speaking of the professor, the article notes how "maintaining information security in a university setting is a challenging task – departments and professors are fiercely protective of their independence and their research." It continues, “To the average professor, those pesky IT security people just get in the way.” Sigh. That is the astonishing naive arrogance (a fool's mixture) we all need to deal with on occasion.

So what are you to do? The only realistic lesson to take from this is to get moving and find all your sensitive data, at least (from this QSA's perspective) your payment card data. And the only way to do that (per PCI, IMHO) is to get an automated data discovery tool. Barring that, I guess we all will be "pesky security people" asking questions and getting dismissive answers.

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.

PCI Summit Presentations

The people at BrightTALK have put together a PCI Summit with a collection of webcasts, some of which you might find interesting...including a particularly informative one on tokenization by yours truly (humble, but I have to be honest...sort of). You can click here to head over to the site and see what's on offer.

Presenters including such PCI leading lights (and friends) as Dr. Anton Chuvakin and Michael Dahn, both of which have enlightened us at the Institute's PCI Workshops.

You may find it a productive use of a lunch hour or two.

Tokenization Webcast

Many Higher Ed institutions are looking at tokenization as a means to reduce their PCI compliance effort (and cost). But tokenization may not always be as easy as it may seem.

Next Tuesday, September 28 at 9 am Pacific Time/noon Eastern, I will conduct a webinar on "Reducing PCI Scope with Tokenization: Opportunities and Challenges." You can surf over to the BrightTALK website and register. If you can't make it that day, they will have the recording available for you to listen at a later date.

I will explain the basics of tokenization, what it can and cannot do, and some important questions you need to ask before you plunge into it. I am very excited about this webinar, and I hope you and others will find it useful.

Cyberthieves Hit Another University

This post isn't PCI-related, but it does address your security and your money, so read on...

According to a report in Krebs on Security, cyber thieves made off with nearly $1 million from a University of Virginia satellite campus:

According to several sources familiar with the case, thieves stole the funds after compromising a computer belonging to the university’s comptroller. The attackers used a computer virus to steal the online banking credentials for the University’s accounts at BB&T Bank, and initiated a single fraudulent wire transfer in the amount of $996,000 to the Agricultural Bank of China. BB&T declined to comment for this story.

Sources said the FBI is investigating and has possession of the hard drive from the controller’s PC. A spokeswoman at FBI headquarters in Washington, D.C. said that as a matter of policy the FBI does not confirm or deny the existence of investigations.

The attack on UVA Wise is the latest in a string of online bank heists targeting businesses, schools, towns and nonprofits. Last week, cyber thieves stole more than $600,000 from the Catholic Diocese of Des Moines, Iowa.

What's wierd about this is that usually the funds are transferred in smaller amounts so as not to get the attention of banks or the victim.

I spoke about this risk at the Treasury Institute's Symposium earlier this year. Several attendees said it couldn't happen to them or their school. I hope they are right. But I wouldn't plan on it. I know some of the Treasury people at UVa, and they are sharp, professional, and very capable. If this can happen to one of their campuses, it just might be a warning to everyone.

Do you have, say, an extra million or so? Probably not, so it may make sense to have a conversation with your bank about when they will and will not authorize electronic transfers.

Just a suggestion. Now, I'm going back to PCI...

Visa Best Practices for Payment Applications

Visa has just come out with its latest in what I hope will be a continuing stream of Best Practices documents. This one is Visa Top 10 Best Practices for Payment Application Companies. You can click here to download a pdf copy.

This document is not just for application developers. It also is for any school (or other organization) that buys software applications. As such, I really recommend you read it.

PA-DSS, like PCI DSS, is a baseline. It is the minimum you need to do to protect your application. PA-DSS addresses how the app is developed. It doesn't address things like training users and not storing cardholder data in the first place. This latter point is one I often find that users don't understand. Because an application is PA-DSS validated does NOT mean the application doesn't store cardholder data. It only means that if it does, it treats it securely. Therefore, don't assume because you are looking at a PA-DSS application you are automatically saved from the joys of SAQ D.

As Visa says on it's website:

While many payment application vendors have deployed PA-DSS compliant payment applications, there is growing concern that updates to payment software are not being consistently developed to ensure that known vulnerabilities are not being reintroduced. In addition, there is concern that payment software is not being securely implemented at customer sites. Merchant and agent compromises reveal that a number of payment application companies have poor software practices when installing payment applications and systems, support customers using weak, shared or default access credentials, and manage customer sites using poorly implemented remote management tools. Criminals exploit these poorly guarded entities by gaining easy entry into cardholder environments.

To stay on top of these trends, Visa has developed a set of best practices to help payment application companies address critical software processes.

When you are looking at a payment application, by all means first go to the list of PA-DSS validated applications maintained by the PCI Council. Then as you are assembling your RFP or looking at vendors, use the 10 Best Practices to guide your decision.

PA-DSS is a baseline, and it is a good one. Visa has gone one step beyond this in recommending its 10 Best Practices to software vendors (and resellers and OEMs). You should use these same Best Practices in your evaluations, too.

PCI DSS v2.0

Wouldn't you know it...I go away for a week's vacation and the PCI Council announces the outline of the changes to PCI DSS version 2.0. Well, I might be a little late, but here are the key links you need to look at.

First, here is the link to the press release. The Summary of Changes is here.

This is likely to be all we will see until the PCI Community Meeting in September.

Phishing Does NOT Take a Vacation

I just heard from a school that one of their campus merchants received a phone call today from a caller identifying themselves as "PCI." The caller wanted the merchant to go through some sort of "authentication process" that would install a "data compliance patch" (read: malware) on their terminal. The merchant very intelligently requested a call back number, which the caller would not provide (surprise...).

The good part is that it looks like this school's training program paid off. The merchant didn't do what the caller/criminal wanted, and they contacted their school's PCI coordinator to report the incident.

I'd ask each of you a simple question: If one of your campus merchants got a similar phishing call, are they trained to react the same way as the person above and refuse to go along with the request? If your answer is anything -- ANYTHING -- but a firm "yes," you might want to take a fresh look at updating your training program.

In the meantime, I'd suggest every school pass the word to their merchants that the bad guys are not taking the summer off. Do not let your school get trapped in a social engineering payment card scam.

PCI DSS Update

Thanks to NACUBO's partnership with the Treasury Institute and their becoming a Participating Organization, I listened to an "open mic" session with the PCI Council. I heard some interesting information.

First, we can expect the revised DSS to be officially "version 2.0." This is not necessarily big news, and it reflects the new 3-year lifecycle rather than any extensive changes expected. NACUBO (and any of you who are Participating Organizations) can expect a summary of the changes around August 12, which is before they will be made public.

The revised DSS will be "pre-released" in September, probably just before the Community Meeting on the 21-23rd. Version 2.0 of the DSS will be released to the public on October 28th. Based on the new lifecycle, version 2.0 will be effective on January 1, 2011, but the current standard v 1.2 will not "sunset" (i.e., go away) until December 2011. Since v 2.0 will be announced at the end of October, that gives you 14 months to comply with it.

There was also news on the Special Interest Groups (SIGs). We can expect to see a report on EMV (chip cards) and scoping at the Community Meeting, with reports on tokenization and point-to-point encryption later in the year.

Both the dates for the release of the revised DSS and the SIG reports are later than I and many others had hoped. Bob Russo recognized this in his opening remarks when he asked for patience from all parties. Meanwhile, mark you calendars for late October!

The Council has recordings of its webinars and open mic sessions on its website (click here) so you can listen to them at your leisure. The webinars are free, but you do need to register.

PCI and Toxic Waste!?!

As many of you know, I frequently refer to electronic cardholder data as 'toxic waste,' or at least I suggest that your view these data as such. Well, now it appears I was more right than I ever imagined.

According to this article at StorefrontBacktalk.com, "huge amounts of the carcinogen BPA were found on 40 percent of the receipts collected from “supermarkets, automated teller machines, gas stations and chain stores."

So now I have to ask each of you another question: why are you retaining all those PAPER receipts!?! Don't forget, Visa says you don't need to keep the data no matter what your processor or anyone else says. So, why are you loading up all those file cabinets with, literally, toxic waste?

Time to either get PCI compliant or call in the EPA!

2010 Data Breach Report Now Available

Verizon Business has released the 2010 Data Breach Report. I'm out of the office today, so for now I'll just refer you to two thoughtful analyses. One is Branden Williams' blog which has highlights and his insights, and another is Brian Krebs' Krebs on Security.

Lots of interesting reading.

User Training and Spam

I recommend you take a look at a post at the SANS Storm Center on using common sense when reading email that appears to be spam, but may not be.

PCI requires that users receive some form of security training. When I address this kind of training, I like to use some phishing examples. This post has another good example along with a thoughtful analysis.

From: Comcast

"This is a courtesy reminder that your Comcast Billing Information needs to be verified.

In order to continue using comcast services, click the link below, sign in and and follow the provided steps:

Regards,
Comcast Billing Department"

So, let's look at this and see how easy this is to detect:

1. I'm not a Comcast customer. So right there, it was easy to detect.
2. "comcast" in the second line is not capitalized. A real Comcast email would have capitalized their own companies name.
3. Usually an email like this (from Comcast corporate) would tend to have all kinds of disclaimers and other nonsense at the bottom of the email.
4. The link that I removed was not to "comcast.com"

Now, if we get into the weeds a bit more, we can look at the headers and see where it came from.

It came from a server at a .edu. I don't want to talk about which .edu (but it was in the United States), as I am going to try and get in touch with their security department after I get done writing this Diary.

I wonder if you or someone at your school is who SANS is contacting...?

Oh, I almost forgot the punchline. Where would this email send you or your users if they clicked on the link? They were taken to a site run by the bad guys that collects usernames and passwords. Not good.

Think about including some live examples like this in your security training. It is interesting, guessing phish from real can enliven the discussion, and it works.

Visa Publishes Guidance on Tokenization, Data Retention

Visa today released its latest two of its "best practices" documents dealing with very important topics. You should download them (below) and read them.

The first is Visa's best practices for tokenization. Tokenization is the process whereby you replace a payment card number with a surrogate value or token. A processor or other trusted third party maintains the ability to reverse the token (e.g., a card data vault). The idea is that the token cannot be reversed, and you use it for all subsequent transactions. If done properly, tokenization can reduce your PCI scope.

While not giving you a complete "how to" guide, the paper has some good implementation guidance if you are considering tokenization. Visa titled the paper "Tokenization Version 1.0" and it is open for comment until the end of August. Presumably we may see a revised/clarified version after all comments are in.

The second paper I recommend to you is Visa's Best Practices for Primary Account Number Storage and Truncation. This is my personal favorite. It repeats (and repeats) what I have been saying for years: as a merchant, you have no need to retain a payment card number for exception items like chargebacks and refunds. I could not say it better than Visa's own words:

Due to misinterpretation of Visa dispute processing rules, some acquirers require their merchants to unnecessarily store full Primary Account Numbers (PANs) for exception processing to resolve disputes. The unnecessary storage of full card PAN information by merchants has led to incidents of data compromise, theft or unintended disclosure during disposal. Additional confusion exists due to inconsistent dispute resolution practices by issuers and acquirers in use across different geographies, leading some merchants to conclude that PAN data must be retained for all transactions.

To clarify, Visa does not require merchants to store PANs, but does recommend that merchants rely on their acquirer / processor to manage this information on the merchants’ behalf. Visa also recommends that acquirers / processors evolve their systems to provide merchants with a substitute transaction identifier to reference transaction details (in lieu of using PANs).

Couldn't have said it better myself! If you are storing PAN data for dispute resolution, I hope you are getting something back from you acquirer because you are doing their work.

I regularly run into this urban myth that merchants "Have to retain the PAN for xxx years/months/whatever." Thank you, Visa. Now maybe we can get on with PCI.

A Bad Week for Higher Ed Security Breaches

This past week has been a bad one for security breaches in Higher Ed.

A few days ago I read about the University of Hawaii - Manoa data breach affecting about 53,000 people. Their parking office system was hacked, and they lost a lot of data from Social Security Numbers to payment cards (take a look at your school's parking permit application, and you get an idea of what was lost).

Then I learned about the breach at the University of Maine that was also announced this week. This didn't involved payment cards, but once again their security was found lacking.

Then to cap things off the whole topic of security in Higher Ed got more visibility with an article in Dark Reading entitled University Databases in the Bull's Eye. The author details these two breaches plus more.

All of this points up the importance of securing your data - all of it. Yes, I know this blog is about PCI DSS and protecting cardholder data, but you also have a lot of other personally identifiable information (PII) lurking in your computers, and you need to comply with HIPAA, too.

The bad guys are out there and they are targeting a number of industries including Higher Ed. That means you are in the "bull's eye." Make sure you are compliant all 365 days a year. You may have vulnerability scans quarterly to meet your PCI requirements, but remember you are being scanned by the bad guys a few hundred times an hour. The difference is they don't give you a report of your vulnerabilities, so maybe give a thought to more frequent (e.g., monthly) scans. Also make sure you reduce your scope. If you are storing cardholder data (like the unfortunate people at UH-Manoa) ask yourself: WHY!!! Is it worth the risk? When did you start putting your institution at risk under the false banner of "customer service?"

Lastly, watch out for data seepage. Most of you who retain cardholder data know where those data are...you hope! Often it is the faculty or staff workstation that has old data and was never purged that is vulnerable. Another risk is when the data are stored (against policy, but gosh, it sure was convenient...) and you don't know about it. Are you using a data discovery tool to find these data seepages?

Lots to think about during these summer months.

PCI DSS Lifecycle Webinar

The PCI Council will hold a webinar on June 22 (repeated on June 23) addressing the current 2-year lifecycle of the PCI DSS. To view a description and register for either session, click here.

According to the Council's press release:

The one hour webinar, hosted by PCI SSC General Manager Bob Russo, will provide a brief update on the lifecycle used to manage PCI Security Standards development, followed by a live Q&A session.

The presentation will outline:

• PCI SSC standards development
• Overview of current lifecycle
• Changes to current lifecycle

You need to submit questions in advance to a website listed in the press release.

As I've previously noted, the Council is evaluating whether to go from the present 2-year lifecycle for DSS to a 3-year lifecycle. The longer time reflects the stable nature of the DSS and matches better with the other standards managed by the Council.

This webinar is the latest in what appear to be a series of communications from the Council leading up to the revised DSS due in October. Bob Russo has promised there would be "no surprises" by the time of the September Community Meeting, and it looks like he and his colleagues are keeping their word.

Memory Sticks Complete with Pre-Loaded Malware

Following is an excerpt from a letter (see here) IBM had to send to recent trade show attendees:

Dear AusCERT Delegate,

At the AusCERT conference this week, you may have collected a complimentary USB key from the IBM booth. Unfortunately we have discovered that some of these USB keys contained malware and we suspect that all USB keys may be affected.

The malware is detected by the majority of current Anti Virus products [as at 20/05/2010] and been known since 2008.The malware is known by a number of names and is contained in the setup.exe and autorun.ini files. It is spread when the infected USB device is inserted into a Microsoft Windows workstation or server whereby the setup.exe and autorun.ini files run automatically.

Please do not use the USB key, and we ask that you return it to IBM at Reply Paid 120, PO Box 400, West Pennant Hills 2120.

If you have inserted the USB device into your Microsoft Windows machine, we suggest that you contact your IT administrator for assessment, remediation and removal, or you may want to take the precaution of performing the steps below.

Now you know why I never, NEVER keep the ubiquitous memory sticks (aka, flash drives) vendors distribute at trade shows. You might want to adopt the same policy. "Free" can be very expensive.

Now, I wonder if the same people who manufacture the flash drives also make POS terminals...

Advice for Keeping Your PC (or Mac) Safe

We all know the Internet is a dangerous place. In case you might harbor any doubts, take a look at this article in today's New York Times describing how to keep the bad guys away from your PC.

The suggestions/recommendations are:

• Protect your browser. If you run Firefox, get NoScript (personal recommendation).
• Download the Adobe updates as they come in, and the sooner the better. PDFs are an increasingly common vector for malware, so keep things patched.
• Don't click on malicious ads. Duh...How about: Don't click on ANY ads!?! And especially, ESPECIALLY don't click on any pop-up telling you that your computer is infected and you need to upgrade your anti-virus. Check with your IT or security department -- that's what they do for a living, and most neither need nor want our help.
• Watch out for poisoned search results. After every disaster, celebrity dust-up, or major news story hundreds of sits spring up with similar-looking URLs to lure you to a site loaded with malware. The bad guys know how to tweak the search engine results, so steer clear of one-off sites.
• Keep away from social exhibitionism -- er, networking -- sites using any computer that you might remotely want to use for business.

There you have it. Read the article and surf carefully. It's a dangerous place out there!

PCI is Required - Even if Your Bank Doesn't Call You

One of the complaints I hear regularly from schools it that they have not had much contact with their acquirer or processor about PCI. In some cases, when they tried to talk to the acquirer they were either unable to get hold of someone in the Compliance area or their calls went unanswered.

While that may describe your situation, you don't get a free pass on PCI. To make this point, let me suggest you read this article in Forbes. The author also makes some excellent points about how you can lie on your SAQ, but you are really only fooling yourself. This gets back to the Validation-does-not-equal-Compliance argument I have made too many times already.

There are some great quotes from Anton Chuvakin and Martin McKeay, both of whom are PCI and security experts as well as friends.

Next time someone asks you about whether you think it's worthwhile complying with PCI, point them to this article.

PCI Council Releases New PCI PTS Today

The PCI Council today released the new version of its PIN Transaction Security (PTS). This new version 3.0 streamlines requirements for manufacturers. There is a good overview in Dark Reading, so I won't repeat it all here.

As merchants, the big thing for you to know about this is that if you are replacing or upgrading your PIN devices, you need to go to the PCI Council website and look at the list of approved devices. Many of the requirements in v3.0 won't be effective for about a year, but that doesn't mean you should buy PIN pads or kiosks that accept PIN-based debit or anything that takes a PIN that isn't on this list.

PCI Workshop #7 Is Over

This week saw the Treasury Institute's seventh PCI Workshop in Indianapolis. We had about 140 attendees representing over 80 institutions nationwide. The agenda covered a good range of business and IT topics of current interest. Highlights included the great Higher Ed speakers who devoted the time and energy to share their experiences with PCI with the audience.

Two other highlights were our keynote speakers, Anton Chuvakin and Bob Russo. You can read Anton's take on the workshop (hint: he found it an education, too!) here and even download his best PCI presentation ever. BTW, if you download it, you might not want to share the 'kitten bit' slide (see his post script) with your children... Bob's always dynamic and informative presentation covered developments at the PCI Council including some general ideas, but nothing on the revisions to PCI in October. (Note: Bob made me promise not to blog about anything he said, so I am not going to get in trouble with him...again...)

Our expert panel -- which included both Anton and Bob plus Don Roeber of Fifth Third Processing Solutions and Marco Mabante of Elavon -- was outstanding. They answered questions on PCI scoping, hotel compliance, tokenization and end-to-end encryption, SAQs, and a whole host of specific attendee questions.

Congratulations to Dennis Reedy and the Treasury Institute for a great workshop. If you missed it, mark your calendars for early May next year when we'll do it all again but with a completely different program, as usual.

I don't know about the rest of the attendees, but I'm pooped. So I found the perfect way to relax and recharge: I'm running the 500 Festival half-marathon tomorrow (Saturday). Wish me luck!

What to Expected for PCI in 2010

The PCI Council held its latest Open Mic session last week where Bob Russo briefed callers on new developments at the Council. These webinars are a great two-way communication between Participating Organizations and the Council. Bob and his colleagues from the payment brands also fielded a number of questions although they explicitly avoided any comment on possible changes to the PCI DSS expected this fall. Earlier, Bob had given press interviews where he said he did not expect any major changes to PCI DSS this year.

Those of you who follow me on StorefrontBacktalk.com know that I reported on a presentation at the Electronic Transaction Association meeting where some of the preliminary directions were presented. Nothing is yet finalized - indeed, as I also reported, the Technical Working Group was meeting at the same time as ETA and still discussing possible changes.

While there is nothing official, we can do a little informed speculation. As I reported, I expect there will be clarification of some requirements. I think we'll also see some very welcome papers on emerging technologies that promise to make PCI compliance easier.

All of this is welcome news and supports the Council's position that PCI DSS is a stable standard that still can respond to emerging threats and new technologies. On the webinar, Bob gave the impression that information will be coming out in stages over the summer.

As soon as information becomes public, you can count on seeing it here. And for those of you attending the Treasury Institute's PCI workshop next week, you will have the opportunity to hear from Bob directly on developments at the Council.

Your Copier and PII

I saw this report on copiers and how the images they store are retained. I suggest you give view it and do some hard thinking.

Copiers and many fax machines retain electronic copies of the images they process forever. Yes, forever. The images are stored on the machine, and when you trade in your machine, you trade in all those images, too, which go to the next owner.

These machines can be an issue not just for PCI, but also present HIPAA challenges and, indeed, all forms of PII (personally identifiable information) can be there from tax returns to official documents.

There are encryption modules, and it might be worth exploring these for copiers and fax machines used in areas where you process payments. They cost extra, but they could be worth it. Come to think of it, I hope every law firm, hospital, and payment back office has such encryption. Yeah, and I probably believe in the tooth fairy, too, and that the Giants will win the pennant and that I'm going to run a 2-hour marathon.

What is the risk? The machines are not easy to take apart, and you need some expertise to get the information off the storage device. But the bad guys have already figured out how to break into everything from banks to card processors, so it isn't too great a leap to believe they can dig through your copier, too. That is especially the case if the copier is from a payment operation.

On the good side, maybe a little FUD will keep your staff from using the office copier for their tax returns...think of the paper and toner savings!

OWASP Top 10 for 2010 Released

The Open Web Application Security Project (OWASP) has updated its Top 10 web application vulnerabilities. Click here to access the OWASP site and download the document. From the website:

The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2010 version are underway and they will be posted as they become available.

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

PCI requires that if you develop custom code for payment applications, the code must be assessed against the vulnerabilities in this list. So if you have developers, make sure they get the word about this update.

Cybersecurity and Risk Assessment

You have yet another opportunity (obligation? curse?) to inform and educate your senior management about how important is the work you are doing to protect your institution from a damaging data breach.

The American National Standards Institute (ANSI) last week released its report " The Financial Management of Cyber Risk - An Implementation Framework for CFOs." I recommend you download it by clicking here (you will need to register, but it's free thanks to the good people at ANSI).

Then give it a good read. It makes the case that:

In reality, cybersecurity is an enterprise-wide risk management issue that needs to be addressed from a strategic, cross- departmental, and economic perspective. The chief financial officer (CFO), as opposed to the chief information officer (CIO) or the chief security officer (CSO), is the most logical person to lead this effort.

The report assigns dollar figures to breaches (nothing really new here, but more credibility). And speaking of credibility, a blog post from SANS Storm Centyer stated that:

The report is endorsed by Melissa Hathaway, former Acting Senior Director for Cyberspace for the National Security Council. The CFO guide is a direct response to the Cyberspace Policy Review released last May. That report stated, "Between 2008 and 2009, American business losses due to cyberattacks grew to more than $1 trillion in intellectual property." Copies of the documents from the Fed review can be found on the White House website. (http://www.whitehouse.gov/cyberreview/documents)

I found several chapters interesting, particularly Chapter 2 on educating users. Also there are some great appendices including one on insurance (really!) offered by various companies.

It all goes back to the theme that risk is a multidisciplinary issue that should be addressed in a multidisciplinary fashion.

On the Web, Every Day is April Fool's Day

It isn't just the Google, er, I mean Topeka site. Every day on the Web is April Fools Day. See this article from the New York Times and see if maybe you should include some of this in your end user training.

And no, that's not an April Fool's joke.

Visa's Keylogger Alert

Visa recently issued a security bulletin alerting merchants to an increase in keylogging attacks. you can download a pdf of the bulletin here.

Your users can download keyloggers from an infected email (usually an attachment or a link to a malicious website), a USB drive or CD someone sent you (or you borrowed...bad boy/girl!), or even directly installed by an insider with access to the victim's computer.

Visa states that:

The particular key logger malware identified by Visa is equipped to send payment card data to a fixed e-mail or IP address accessible to the hacker. In these instances, the hacker is able to install key logger malware on the point of sale (POS) system due to insecure remote access and poor network configuration. Based on Visa’s review of the malware, it uses File Transfer Protocol (FTP) and Simple Mail Transfer Protocol (SMTP) on default ports (20, 21 and 25 respectively) to send data out of the network.

The bulletin goes on to suggest a number of mitigation strategies.

BTW, for those of you who think you are immune or that no one would want your banking credentials, you obviously haven't read my previous warning. If that's not enough, you can check out Krebs on Security's latest example of bad things happening to good people.

Download the bulletin and think about your user training. The web is a dangerous place.

Credit Card Pricing: Do You Check Your Statements?

While I mostly deal with PCI and PCI-related issues, the topic of acquirer pricing does come up occasionally. Today I saw an article about payment card pricing that I think is worth your consideration.

The topic is whether you are better off with 'interchange plus' (quick answer: yes you are) pricing as opposed to 'tiered pricing.' Some acquirers are better than others at passing along to you the best pricing. Indeed, there is a mini-industry that has sprouted up to examine your monthly merchant statement(s) and see if you have had inappropriately downgraded (i.e., more expensive) transactions.

As you consider processors, make sure you tell them you want interchange plus pricing. Also work with them to make sure you don't have a lot of transaction downgrades. I have often started a PCI project by performing a payments analysis, that is, looking at transactions by brand and by interchange type. This helps me understand all the different payment channels in use as well as providing a good overview of the school's card business. I frequently see lots of MOTO and other card-not-present transactions at higher interchange rates than I would expect.

Take a look. Then look at your monthly merchant statement and make sure you are getting all that you are paying for...and not paying too high a price.

Hotels and Data Breaches

As I've noted before (see here and here), if your school has a hotel - whether you run and operate it or your outsource it - that hotel can cause PCI compliance challenges. This article in WSJ Online confirms that hotels are particularly vulnerable to data breaches.

As you map out your compliance strategy and approaches, keep it in mind.

The PCI Council Speaks

Fellow blogger and good friend Anton Chuvakin (aka, Security Warrior) managed to score an exclusive interview with Bob Russo and Troy Leach of the PCI Council while at the RSA Conference. (I think I'm hurt...Bob only talked informally to me.) Click here to read it.

In the interview Bob (General Manager, PCI Security Standards Council) and Troy (Chief Technology Officer) make a number of good points about the need for merchants to be educated about what PCI is and how it can protect them. They also rightfully emphasize that security of your systems and data is paramount.

I found a couple of things particularly interesting. First, they seemed to dismiss my forecast that the revised PCI standard will require automated data discovery tools. Darn; missed that one. Another suggestion that I and others have pondered is the development of tiered compliance requirements, maybe one for small merchants and another for larger ones; or maybe one for merchants and one for processors. Bob and Troy knock that one down, sadly, but with good justification. I still think the idea has merit and ought to be explored.

Here's your bonus. Both Anton and Bob will be keynote speakers at the Treasury Institute's PCI Workshop in May. Maybe this time you can be the one to score an exclusive interview with one or both of them! Registration is open (shameless plug...).

Your Policies, Follow-up

There is a great post at Security Catalyst on why you need a privacy policy. It covers a lot of territory and compliments my previous posts (part 1, part 2, and part 3).

Here's the rationale/reasoning...

So to summarize, here are the 7 reasons you need a privacy policy:

1. If you have customers or employees, you need to safeguard personal information.
2. Laws do not usually establish Privacy Practices. Privacy Policies create Privacy Practices.
3. Privacy Policies are often required by law or regulation.
4. Your business faces privacy challenges which nobody else faces.
5. Cloud Computing, Social Media, Goods and Services, Employer, and other activities pose unique challenges to handling personal information.
6. You must comply with specific regulations if you have customers or employees in specific states or the EU, or if your servers (or the servers of a subcontractor) reside in the EU.
7. Your company has affirmative privacy obligations with respect to minors under 13 years old.

Perhaps my favorite part is describing policies not as a "necessary evil," but just "necessary." Have a read, then take a look at how your institution is handling access to social media, iPhones, and all other forms of information including (ahem...) payments.

Is Your Schools' Bank Account About to be Emptied?

If you don't follow Brian Krebs' blog, you ought to. He has posted a series of reports (the latest is here) of small and medium sized companies having their bank accounts emptied by fraudulent wire transfers. The culprit is the Zeus Trojan.

I talked about this attack vector at the Treasury Institute's recent Symposium. Some people felt they didn't need to worry since they have dual authorization on wire transfers. That may be the case, but please, please protect yourself from this attack by isolating any computer used to transfer funds. That is, don't use it to check your Facebook page or surf the net...EVER!

So far a number of small companies have been victims, their money disappearing to the Ukraine and other spots. The wire transfer companies got their fees so they don't care, and your bank will likely blame you - possibly with some good reason.

You don't want to join the ranks of Zeus victims.

Call Center Recordings - Version 3

Yesterday (Feb 17) the PCI Council re-revised their call center FAQ with more clarification on whether you may store digital recordings containing the security codes (CVV2, CVC2, etc.).

Here is the text of the FAQ (link here). The first two paragraphs are the explanation that the Council heard the issues from their previous clarification (see here) just a couple of weeks ago. The next two paragraphs are unchanged:

PCI SSC FAQ’s are designed to provide merchants, assessors, acquirers and other Council stakeholders with clear and timely guidance on PCI standards. They are a critical two way communication channel from which the PCI SSC draws valuable market feedback and insight, and is able to share this with the industry. On January 22 2010, as part of the online FAQ feedback and submission process, the regular
review of FAQ language, and inquiries from Participating Organizations the SSC sought to clarify its position on call center audio recordings.

The updates to the FAQ language were intended to eliminate any inconsistencies in implementations of audio recordings in call center environments by providing a higher level of specificity in FAQ guidance. The Council’s position remains that if you can digitally query sensitive authentication data (SAD) contained within audio recordings - if SAD is easily accessible - then it must not be stored. As a result of additional market feedback, on February 17, 2010 the SSC modified the new language to further clarify its position on audio recordings. Please find this language below:

This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

Now this is where it gets interesting. The phrase "if that data can be queried" is new, and the Council emphasized (bolded) it. This sentence in the previous FAQ ended here. Storage of digital recordings was verboten, period. Now, it looks like there may be some room. The paragraph after is some good advice.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried [Council's emphasis]; recognizing that multiple tools exist that potentially could query a variety of digital recordings.

Where technology exists to prevent recording of these data elements, such technology should be enabled.

The final paragraphs are also changed. Where previously the only exceptions to recordings containing the security codes were analog tapes (as if anybody still used them), now there is much greater leeway. The new FAQ - or FAQ v3 as I call it - now says you can keep the digital recordings so long as you protect them per PCI. The last paragraph is simply recognition that sovereign law supercedes PCI:

If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.

This requirement does not supersede local or regional laws that may govern the retention of audio recordings.

Where does this leave us. Let me try and summarize:

• Call centers can now store digital recordings containing sensitive authentication data like the security codes. Yesterday they couldn't. Last year they couldn't.
  
  
• The PCI Council got sufficient market feedback from the previous FAQ that they took the issue back to the Technical Working Group and the 5 brands. The result is this revised position.
  
  
• Up to this time, the only exception to the rule prohibiting storing the security codes was for system testing, and that had to be tightly controlled. Now call centers can retain tons of digital recordings and protect them per PCI. BTW, if you do this don't even dream of using a simplified SAQ!
  
  
• There are bound to be questions about what it means to have records that "cannot be data mined." Will this mean encryption? Maybe. Does it mean keeping the data offline? Possibly. Should you restrict access? Plan on it. In fact, if you have these recordings I'd plan on getting some expert guidance to make sure not only that you are compliant, but that you are secure!
  

For more information, see this column in StorefrontBacktalk (full disclosure: as you know, I am PCI columnist for SFBT).

PCI Training

Getting good PCI training is critical for anyone involved in getting their campus(es) compliant with PCI DSS. As most of you know (I hope!) the Treasury Institute offers a 3-day PCI Workshop annually. The next one will be May 3-5 this year in Indianapolis (click here to learn more). The Institute has also offered a 1-day PCI Workshop twice.

The PCI Council offers 2-day PCI training based on the course required for each Qualified Security Assessor (QSA). According to the Council:

This is a 2-day training course based directly on the PCI SSC Qualified Security Assessor (QSA) training program. Attendees will learn what the QSAs learn so they can better prepare for an on-site PCI DSS assessment or perform the assessment internally. This is not a certification course.

The course will cover: PCI Program, Scoping a PCI DSS Assessment, PCI DSS v1.2 Requirements and Compensating Controls

You can learn more and get the current schedule here on the Council's website.

The two programs are different. The Institute's workshop is focused on the unique needs of Higher Education and it features case studies and great networking with other schools. The Council's training is very technical in nature and provides a wider perspective on issues across industries and possible approaches.

Visa used to offer a 2-day course also modeled on QSA training, but I don't see that on their website currently. If you are interested in this, check with your acquiring bank. They have to register you anyway.

You could arrange for a PCI trainer to come to your campus and conduct customized training for you. This can have cost advantages since it minimizes travel and registration costs. You also can have different staff attend those parts more appropriate to their jobs. I've seen great examples at individual schools who make it part of a "security day." It can also work well for groups of schools that are part of a common university system.

Whatever way - or ways - you choose, compare costs, compare approaches, and get yourself trained. It pays great dividends.

Compromise of Chip Cards

There is a lot of buzz in the security world over the successful compromise of some European chip cards. A group of Cambridge University researchers demonstrated that they could trick a terminal into authorizing a transaction even though they did not know the PIN. In other words, they managed to convince the chip card that they had a signature-based transaction while they simultaneously convinced the POS terminal that it had a PIN-based transaction. They could put in any PIN and the transaction was authorized.

There have been past instances where researchers have compromised a chip cards, that is, payment cards with an embedded microchip. The idea is that each time the card is used the cardholder has to enter their PIN. Where the system doesn't add much security is when the card is not present (mail, phone, and e-commerce transactions), or when either the chip is damaged or a non-chip card is presented when the terminal reverts to signature mode.

Chip-and-PIN can reduce card-present fraud. No one argues with that. But it is not a silver bullet that will make PCI go away or even make it less relevant.

If you want to see this compromise in action, click here to see the broadcast on the BBC.

New PCI Call Center Recording Rules

If your Development department (or anyone else on campus) records phone transactions, you need to take a look at the PCI Council's revised FAQ on these recordings. You may need to upgrade or replace your recording system or, failing that, stop call recording altogether.

The issue is recordings that include card security codes, e.g., CVV2, CVC2. Many Development and Advancement departments record complete donor calls during phone-a-thons. These recordings have always been in scope for PCI, but if they were not searchable you could keep the security codes, too. This amounted to a free pass for Requirement 3.2 which states you may not store any sensitive authentication data.

The free pass was revoked January 22 when the Council issued a revised FAQ on call center recordings. The Council stated:

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

The Council's reasoning was:

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors.

What does this mean? If you have a digital voice recording system, you will need to purge all your old recordings of the security codes. Then you need to configure/upgrade/replace your call recording system not to record these codes on all new recordings.

The Council carved out a minor exception for analog or tape recordings since these are not searchable. It reinforced, however, that even these recordings are in scope for PCI.

To see the complete FAQ go here. Then take a look at your IT budget to see if you have a line for new/upgraded call center recording software. Then again, maybe you don't need those recordings after all.