Friday, September 25, 2009

Purchasing, Travel, and Corporate Cards and PCI Scope - Some Closure!

I have blogged here (see here with comments, and here, and here) and elsewhere about whether “corporate cards” used for travel and purchasing should be in the “issuing” school’s own scope for PCI. In other words, if a university (or Megacorp) issues Visa or Amex cards to their staff for travel or purchasing, somebody in the school’s finance or purchasing department will have lists of the PANs. Are these PANs for the cards issued by the university in the university's PCI scope?

Some (including this QSA) feel a PAN is a PAN, and as such these cards are in the issuing school’s scope and the data should be protected per the DSS; others (equally or more qualified) believe the cards are out of scope. This topic came up again at the QSA/ASV session at the PCI Community Meeting this week, with the suggestion that it was a “brand issue” and I should check the FAQ. So…

Here is the FAQ (number 8715) and the Council’s response:

If a merchant or service provider has internal corporate credit cards used by employees for company purchases like travel or office supplies, are these corporate cards considered ‘in scope’ for PCI DSS?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data. Whether entities with cardholder data on their own corporate cards need to validate compliance is determined by each payment brand individually. Depending on the marks on those corporate cards, please contact the applicable payment brands listed below for their validation requirements: american.express.data.security@aexp.com askdatasecurity@discoverfinancial.com riskmanagement@jcbati.com sdp@mastercard.com cisp@visa.com

Wow…not a lot of help there. So, I contacted each brand, and here is what I learned.

First, both Visa and MasterCard responded within hours, and Discover replied in just over a day. Kudos to each of these brands for the speedy responses! I got American Express’ reply a bit later by speaking directly to their top PCI people at the PCI meeting. I’m still waiting for JCB, but since I’ve got most of the landscape covered with these 4 brands, it’s worth sharing their responses now.

  • MasterCard won the prize for succinctness: “MasterCard considers these cards in scope.”

  • Discover replied similarly: “Per the requirements of the DISC program, which may be found on our Web site, any payment card bearing the Discover logo is considered to be within scope of the PCI DSS.”
  • Visa was the winner in the fastest response sweepstakes. They provided, however, a more nuanced response: “As stated by the PCI DSS, any entity that stores, processes, or transmits cardholder data is within scope. The corporate card data itself would not be within scope of an entity's PCI DSS compliance VALIDATION scope but should be secured in accordance with personally identifiable information restrictions. However, if the entity's corporate card information resides in the same systems or unsegmented network as their merchant payment card processing environment, the systems would be within the entity's PCI DSS compliance VALIDATION scope.” [emphasis is Visa’s, not mine]

    I translate this to mean if the corporate card data are housed in the merchant’s cardholder data environment, then and only then would the corporate card data be in scope. Otherwise, treat the data like you treat other sensitive corporate data or PII.
  • Amex’ response to me at the PCI Community Meeting was that Amex corporate cards are out of the issuing school's or company’s scope. Amex believes they should not require the company issuer (or any cardholder) to do anything special; it’s up to the issuing company.

To summarize, the answer to the question "Are corporate card data in scope for PCI?" is: it depends. Everybody agrees that you should protect the data, but not every brand is going to require it:

  • Corporate/travel/purchasing cards with the MasterCard and Discover logos are in PCI scope for the issuing school.

  • These same cards with the American Express logo are out of scope for the issuing school.

  • These same cards with the Visa logo are in scope only if the corporate card data are stored in the merchant cardholder data environment.

Do I agree with all of this? Well, first of all it doesn't really matter. But I find myself closer to the MasterCard and Discover position, and I would advise any school to protect their corporate and purchasing card databases. Ideally, you should protect them per PCI. You can get in the headlines just as easily for losing these cards to a hacker. As for any financial liability if you lose the data...I'll have to leave it up to you to check your contract.

Apologies for the long post (sorry, Dennis!), but I thought it important to share the details with all Treasury Institute followers and other interested parties. I look forward to hearing any additional comments others may have.

Thursday, September 24, 2009

PCI Community Meeting - Day 2

Day 2 of the PCI Community Meeting is just concluded.

We heard from former Representative Tom Davis about the prospects for federal legislation addressing cyber security. My take from the presentation is that such legislation is not very likely, and certainly not soon. Mr. Davis pointed out the difficulty and complicated legislative process with a polarized Congress, lower approval ratings for the President who might support such legislation, and importantly the barriers between the many federal agencies involved and general Congressional inertial. Statutory changes - barring a crisis such as a "cyber Pearl Harbor" - it is unlikely the many committees in the House and Senate with jurisdiction will act. We might see more hearings like those this Spring, so at least keep the popcorn popper handy.

A major element in today's schedule was the report from the PIN Transaction Security working group. I am not an expert in this area, and I won't pretend to follow all the many technical details around each of the various hardware components involved in a PIN-based transaction. But one thing I did learn was to tell you that if you are looking at purchasing or installing any kind of unattended payment terminal (UPT) such as a parking lot or ticketing kiosk, or if you have other kind of devices that accepts PINs whether they are attended or not, make sure the vendor hardware is compliant and listed. There are a lot of products, and many vendors have devices that are and are not compliant, so make sure to check everything out at the Council's website.

And again today, the Listening Meeting continued with a lot of feedback from merchants, vendors, QSAs, and maybe even an Elvis impersonator or two (you know who you are...). The Council will be posting presentation overheads and recordings on the website in a few weeks.

Now, if I can just make the standby list and get an earlier flight back home...

Wednesday, September 23, 2009

PCI Community Meeting - Day 1 at The Listening Meeting

I'm here in Las Vegas with 650 of my closest PCI friends, including Tom Davis of Indiana Univeristy (For those of you who forgot, we represent NACUBO which is a Participating Organization). The PCI Community Meeting - this is the third - seems about twice as big as last year. I guess that makes sense since there are now over 500 participating organizations, 203 QSA firms, 145 ASVs, and 8 PED labs.

If I had to give this PCI Meeting a title, it would be "The Listening Meeting." The Council is in it's feedback phase, soliciting feedback from all parties on the DSS (and PA-DSS) and how it should be changed, massaged, edited, clarified, expanded, contracted, and otherwise revised. In case you missed it, we are scheduled for the next revision to PCI DSS in October '10.

There were some particularly good sessions today. Let me try and describe each and give you the highlights.

The first had Verizon presenting highlights from their 2009 Data Breach Investigation Report. The message reinforced that the threats continue (the role of organized crime; the thriving underground market for card data, etc.) and most companies are not prepared. Not surprisingly, online systems accounted for most breaches, and most companies did not have an incident response plan in place (as I've blogged about before, in case you forgot...). Another interesting statistic: 69% of breaches were discovered not by the breached company but by a third party. Believe me, this is a call you don't want to get.

Another interesting session was the (very) preliminary report from PricewaterhouseCoopers. The Council retained them to investigate emerging payment technologies that could impact PCI: either the DSS itself, or how you as merchant or service provider comply with the Standard. They identified 12 possible technologies and focused on 4 for further study. These were: end-to-end encryption; mag stripe imaging; tokenization; and virtual terminals.

The first conclusion is that none of them is a silver bullet. Sorry to break your hearts, but there it is. Additionally, there are challenges with all of them, and the challenges are not technical. Rather, the challenges are mainly on the business side. Examples cited were:
  • The lack of knowledge and expertise on the part of all parties.
  • The lack of consistency across all parties as to the role/appropriateness of the technology. for example, merchants, QSAs, vendors, and even the Council might have different interpretation of the usefulness of the technology.
  • The need to change procedures for card acceptance/processing by merchants and processors.
  • And somehow making it easier to ensure consistent implementation of the technologies.
The bottom line is that the impact of each of the 4 technologies is likely to be highly variable (translation: no guarantees) depending on how the technology is implemented and the particular environment in which it is implemented. And everyone is still working on making the business case (think ROI), how to integrate the technologies with current merchant and processor environments, and the impact they will have on customers.

My personal summary is that these technologies will shift some part of the burden of PCI compliance from the merchant to the processor (or service provider or acquirer). The merchant will, however, pay more to achieve this shift. Another point is that these technologies might just have an impact on the DSS itself and the scope of compliance. And nobody has worked out the liability and financial consequences for each party. Oh, did I mention that none of them was a silver bullet that would make PCI go away?

We closed the day with a rapid-fire summary from the 4 Special Interest Groups (SIGs). The Pre-Authorization Data SIG has made recommendations to the Council, and the Technical Working Group is starting its review. There can be implications for recurring payments, hospitality/hotels, travel, and of course petroleum retailers with all those wonderful self-serve gas pumps. The Virtualization SIG could have a big impact on many schools and other merchants. They are working on a phased set of releases due to the rapidly changing nature of the technology. Expect a target draft white paper (defining issues, risks, maybe some case studies) in January. Ultimately they plan to produce a mapping tool that will identify where virtualization can apply each requirement of the DSS. I saw some drafts, and it promises to be quite extensive.

The PCI Scoping SIG is just getting started, and it promises to be equally valuable. Too early to report much. But at the other end of the spectrum is the Wireless SIG. They issued their report on wireless (click here to learn more and download a copy), and like the Energizer Bunny they keep on going. Expect a look at Bluetooth implementations next.

In between these presentations were extended "open microphone" sessions where everyone was encouraged to offer their feedback to the Council and the Brands. Like I said, this is The Listening Meeting.

Tomorrow promises to be another full day.

Monday, September 21, 2009

Off to the PCI Community Meeting!

I'm getting ready to head off to the PCI Community Meeting. Tom Davis of IU and I will be there representing NACUBO and the Treasury Institute -- and therefore, YOU. Thanks to those who sent in comments/questions. I have dutifully forwarded them to the Council.

It should be a pretty busy 3 days. First, there's the Tuesday afternoon QSA session. The actual Community Meeting starts Tuesday evening and goes all day Wednesday and Thursday (I wonder if I get two badges...one as a QSA and the other as NACUBO?). I'm planning to blog from the Meeting, so watch this space. I'm also expecting Tom and I will prepare a more detailed report on the Meeting for NACUBO's Business Officer (we're aiming for the November edition).

If you're planning on attending and we haven't connected yet, let me know and we'll find a time to catch up in Las Vegas.

Tuesday, September 15, 2009

Being the "Bad Guy"

Are we in the "no" business?

I have to ask that question because of what I sometimes encounter in PCI assessments and even PCI training. I recommend limiting Internet access or restricting access to cardholder data or changing a business process, and I am seen as interfering with some users' perceived ability to do their job. I am, in their mind, in the "no" business.

I saw an article in Slate subtitled "Why corporate IT should let us browse any way we want." The author's point is that restrictions such as access to social networking sites or "e-mail and chat programs, dating sites, shopping sites, and news sites like Digg or Reddit (or even Slate)" foster resentment, reduce morale, and are corrosive to creativity. Wow. And I thought I was just protecting the client. Is this guy clueless or am I missing something?

I read the Slate piece because of an interesting and very thoughtful post at Security Catalyst responding to it. The thinking is that while you may not agree with the Slate author, you have to admit that he represents what a lot of users -- your users -- are thinking. Instead of just responding with another rant, maybe we need to listen to the objections...really listen. Maybe we ought to take a look at the restrictions to make sure they really make sense. Then, let's educate the users as to why the restrictions exist. Maybe, and this is where we get a little optimistic, we can even convert some of them. (Personally, I'd be happy for a little understanding...).

What do you do? How do you implement what may be seen as draconian controls by some but that are simply good practice from a risk view point? Have you ever tried to convert a skeptical user or bunch of users? How do you address risks in your employee training?

The problem isn't going away. SANS just released its report on the top cyber security risks and the picture isn't pretty. If you want a good idea of the scale of the threats, just read the first part of the Executive Summary for all the vulnerabilities in client-side software, phishing, and web-based exploits. (Note: I'll be speaking on cyber risk at the upcoming Treasury Institute Symposium in January; plan on this subject being included.)

Looks like I and most of you, dear readers, may be in the "no" business for a while, but I like the idea of trying to convert users -- the IT staff are easy -- to seeing why the restrictions are needed.

Any and all ideas welcome!

Thursday, September 10, 2009

UPDATED: More on Choosing A QSA

I previously referenced an article on how to select a QSA. Now there is another article (4 Ways to Get the Most From your PCI QSAs) at Computerworld with similarly good advice.

It all boils down to your taking some time, checking out the actual people who will be doing the work, and cooperating. I'm amazed, surprised, and a little disappointed to hear of a school that views their QSA as an enemy or as somebody with a raging case of the swine flu to be avoided at all costs.

Anyway, remember you are paying, so to get the most for your money pick a QSA carefully and work with them to get the greatest value for your institution.

Update: In an article in Digital Transactions, the CEO of Heartland makes the case for choosing a QSA carefully perhaps better than either of the references above. His point about a low bidders is valid not just for QSAs but for just about any situation. Read it and see if there is a lesson for you in there.

Monday, September 7, 2009

Real Cost of a Security Breach?

There is a standard benchmark used to calculate the cost of a security breach: about $200 per account compromised. But often the compromise is not based on, say, compromised payment cards. Sometimes there is a whole lot of other damage that can run up the bill.

I just saw this article that places the cost of one security breach at a municipal government near London at $822,000. The source of the breach was an infected USB drive that spread a virus throughout the organization. The costs included library fines that couldn't be levied and a lot of parking tickets and fines that were lost. Oh, it cost about $600K in emergency IT effort to fix the damage to the network and systems.

Lesson one: breaches really are expensive.

Lesson two: do you have policies for flash drives (aka, memory sticks) on your campus? Do you enforce them?

Thursday, September 3, 2009

Procurement Cards Can Be Breached, Too

The University of Vermont reported that up to 240 university-funded procurement cards appear to have been compromised/breached. I don't know all the details, but it gives me the opportunity to raise two important points.

The first is that your procurement, purchasing, travel, whatever cards are payment cards. They have PANs. They can be compromised and when that happens many of these cards with their high limits are pretty attractive to the bad guys. AND, they are in your PCI scope. Nothing in PCI talks about merchants only: PCI applies if you store, process, or transmit payment card data. Many schools have databases sitting in their Procurement or Treasury departments and trust me...if I do your PCI assessment, they will be included in your scope.

The second observation is that reportedly, the university found out when their bank called them. Congratulations to the bank. And another example of "you're the last to know."

I am thinking of the old television announcements that used to come on late in the evening: "It's 10 o'clock; do you know where your children are?" I now want to re-phrase that to: "It's time to be PCI compliant; do you know where all your carholder data are?"

Give it a thought.

Wednesday, September 2, 2009

40 Years Young and Going Strong

Where were you on September 2, 1969?

Doubtless, many of you weren't yet born, but I remember I was starting my senior year at college, hoping not to be drafted, sweating grad school admission applications, wondering what this "Woodstock" happening was all about, and trying to figure out my new role as a residence hall counselor (hey, it paid the tuition). While I was doing all that in beautiful Indiana, some folks at UCLA were connecting two computers with a cable. Later, a computer at Stanford Research Institute (where I spent about 10 happy, intense years) was connected and before you knew it ARPANET (Advance Research Projects Agency NETwork) was born.

ARPANET became the Internet which I remember well. Then in the 90's came the worldwide web and the rest, as they say, is history. There is a short video at National Geographic (thanks to SANS Internet Storm Center for pointing this out).

So as you surf over to buy a book, check out a blog, or watch a webcast, quietly sing a verse from "Happy Birthday" to the Internet, 40 years young and going strong!

Tuesday, September 1, 2009

I'm a QSA!

OK, time for a little personal news here... Today it became official: I'm a QSA (Qualified Security Assessor). Until I joined 403 Labs, I could be a PCI consultant, but not a QSA. Now as part of a QSA firm, I could go through the PCI Council's additional training and take the examination. I'm pleased to say that I passed and now I'm officially a QSA.

I guess that means I have to be nice to QSAs now, right?

Bob Russo Comments on PCI and Recent Breaches

The recent breaches and indictments have generated a lot of comments about PCI, many of them unfavorable. On one side are those that say they were "certified" as PCI compliant, but got breached anyway; therefore PCI is worthless. On the other side are those who point out that the breached organizations were not PCI compliant at the time of the breach. They then go on to note that no organization has been breached that was PCI compliant, and that while it is not perfect PCI is still a pretty good standard for protecting data.

A post at the Securosis Blog raises many of these questions. Bob Russo's response follows it. Both are thoughtful pieces with good arguments. I recommend them to you together with the links to the original editorial/article and Bob's response to it.

My own position is that PCI is the best we have. It is a baseline and not a complete security program. PCI can keep you out of the headlines if properly implemented. But compliance is a two-way street: the issues of QSA shopping are real. There are no silver bullets. The answer is to minimize your scope, eliminate cardholder data wherever and whenever you can, and remain vigilant.

Remember, it's time to be careful.