02 July 2008

Surveys, surveys, surveys...

It seems that I can't read a blog or speak with a vendor about PCI without somebody saying "Let's do a survey!" A number of PCI surveys have come out in the past few weeks, and more are on the way (trust me on this one...). But the question I have is: What does it all mean?

I think the fact that there are all these surveys is a positive sign for PCI compliance. It shows awareness of PCI is high. That's good. Schools and businesses worldwide are figuring out that PCI really applies to them, and if they aren't compliant they better get compliant soon. Now everybody is scrambling to learn what the early adopters have learned so they can focus their efforts and avoid duplicating mistakes. Another positive outcome is that we are beginning to get a better grasp on best practices. That is, now that they are monitoring their logs or improving user training, they are wondering what is next.

I have a confession to make: I am not immune to this survey epidemic. Many of you recall the survey we did as part of the Treasury Institute's PCI Workshop in May. I presented the high-level findings at the workshop. Well, the Institute and NACUBO will be publishing the results in a week or so, and I believe you will find them interesting. We'll also be posting a less polished version of the findings on the Institute's website, so stay tuned.

What do all the surveys mean? I think they mean that PCI awareness has grown; that PCI is in the mainstream; that vendors are scrambling to figure out what you need; and that we all want to learn from each other.

These are good things.

30 June 2008

Up with UPTs...?

The PCI Security Standards Council announced today that they are adding two new devices to the Pin Encryption Device (PED) standard. The new devices are unattended payment terminals (they call them "UPT", but think kiosks) and host security modules (HSMs).

I'm particularly interested in the unattended payment terminal part. Many schools have these terminals all over campus: vending machines, parking lots, and ticketing are a few that come to mind.

As far as I can tell, the announcement indicated that the Council will add these classes of devices to the PED standard. There are no devices there yet. But check back as you make plans to use kiosks or other unattended terminals. When devices are tested and approved, you should consult this list just like the PA DSS list for applications and Visa's list of approved service providers.

Now, if we can just find a better name than that annoying "UPT" acronym...

30 June 2008

Stolen Laptops

There is an interesting article about stolen laptop computers in the upcoming edition of the Chronicle of Higher Education. As more people put sensitive data on their laptops and as more of these laptops are lost/stolen, the risk of a data breach has increased.

One solution pursued by some schools is to encrypt the data on the disks. If done properly (i.e., whole disk encryption rather than file-by-file), this helps...so long as the thief doesn't take the laptop while it is running. Another approach is to make it a policy not to have confidential data (e.g., PANs, SSNs) on laptops or any portable storage device, or at least not without explicit permission. Then enforce the policy.

My analysis of higher ed data breaches shows that lost/stolen laptops and storage devices is a problem, but perhaps not as big a problem as hacking. It is interesting to note that the lost/stolen problem is proportionally bigger for businesses than for education institutions. I haven't figured out what that means yet...maybe more business-types leave their laptops in their cars than edu staff types?

Take a look at the article. Then check your own policies and practices: do you have a policy about storing sensitive data on laptops and portable storage devices; how do you enforce it; and when you allow these data to be stored, how do you protect the data?

23 June 2008

Higher Ed Security Challenge

Scott Wright has an interesting post in his blog about a topic familiar to all of us, the disproportionate share of security breaches at colleges and universities. His piece focuses on vulnerabilities through email, and it is well done.

This situation is not news for many of you. Dennis Reedy and I wrote about it a while ago for the Association of Financial Professionals (click here to download the article). Visa even explicitly refers to "universities" as high risk merchants (see this link, and check out page 3). The fact that so many of you attend the PCI Workshops and read this blog (as well as use Educause resources) prove that we all recognize the problem.

Scott concludes his post by observing: It’s about time, we started educating all staff and students at universities on the many specific types of risks that they are facing in their environment. They can’t be happy about being at the top of the breach list every week.

My conclusion is that "educating all staff and students" can only go so far. Instead, maybe we need to change the game from one of protect-protect-protect to no longer storing -- or at least minimize the storing of -- sensitive data, whether SSNs or credit card numbers. Call me a defeatist if you will, but at least a part of wisdom is knowing what you can and cannot change, and it seems like changing the attitudes and habits of thousands of students (who think they are are immortal) and faculty (who know they are immortal) is not likely to happen real soon. Therefore we need to focus on not having sensitive data lurking around our systems and on laptops and departmental servers.

Therefore, (those of you who know me can see this coming) we are back to the mantra of "if you don't need it, don't keep it."

19 June 2008

Friday Reading List

Although it is the start of summer, there is a lot happening in the PCI world and elsewhere. Here is a very personal list of recent publications and posts on other blogs that I offer for your consideration.

How would you like to come into work and find yourself accused of having inappropriate material (i.e., porn) on your computer? This article describes how malware was accidentally installed and proceeded to download some really bad stuff, getting the user in serious legal trouble. Rich Mogull took the story a step further and wrote an excellent post about it and where it could lead. Have a read and think about how easy it is to make decisions based on circumstantial evidence, and how we sometimes take a “guilty until proven innocent” approach in some situations. Maybe it is because I just spent 2 weeks as a juror, but the whole idea of circumstantial evidence and what prosecutors try to do with it is pretty scary, IMHO.

I blogged twice( here and here) this week about logs and logging. More information is at Verizon, and Information Week's analysis. Lots of good stuff there. Also Anton Chuvakin wrote about logs in his blog with his usual insight and has many more references.

Did you see the latest on the Society of Payment Security Professionals? Check out Mike Dahn’s post on the Society and the new Certified Payment Security Information Manager (CPISM) designation. If I were looking for a software or security vendor, or if I were looking at a new acquirer, I’d be asking about whether they belonged to the Society and whether they had people pursuing the CPISM designation. (Full disclosure: I am a member of the Society and serve without compensation on their board of advisors. I did both because I really believe in what they/we are doing. Vendors have to know the payment business; you don’t have time to train them.)

What can HIPAA learn from PCI? Check out this article in SC Magazine and see. I'm not a HIPAA expert, but I found it interesting.

And if you have not yet figured out that the web is a dangerous place, read this story. Recent studies have indicated web-based attacks frequently originate at legitimate sites. The article describes how even security vendors’ sites are not exempt.

Happy reading.

18 June 2008

Why Logs Matter - Part 2, A Letter

Dear SAQ “C” User,

Let me offer my congratulations. You limited your PCI scope and stopped keeping cardholder data electronically. You figured out size doesn’t matter and you validated compliance using SAQ C. I’m so proud of you.

I know you got tired of hearing me describe compliance as a Zen journey without an arrival, but PCI really is about going forward. It is not about looking back. Therefore our job is to make sure you stay compliant tomorrow, next week, and through the year. That is our challenge now, and one thing that can help us might be using good log information.

Logging!?! You certainly noticed that SAQ C contains parts of all 12 PCI requirements except Requirement 10 (the log requirement). You probably thought logs were only for those unfortunate souls who have to deal with SAQ D…and right now you are probably wondering about my sanity. But read on.

Many of the SAQ C questions deal with paper records and internal policies. Things here are unlikely to change suddenly and throw us out of compliance. But there are changes that can have us out of compliance and vulnerable to a security breach and we might not know until it’s too late. For example: did somebody change a firewall configuration; is the anti-virus updated and were the latest patches installed within 30 days; is vendor access being restricted or left open; did someone add a new account with access to the payment server; did anyone add a server or plug in a new wireless network? These are hard things to monitor, and missing any one of them leaves us vulnerable.

You know, those clever people in IT do a lot of logging. They keep track of all kinds of things. I bet we could have them track and report on the things above, things that can jeopardize the security of our students, alumni, parents, and friends. They can alert us if something important changes, and send us status reports on other items. In other words, we can use their logs as a management tool to help us maintain a secure payment environment. Their logs can’t do everything, but they might be able to help a lot.

We agreed when we started this whole PCI thing that the big idea was to protect the institution. You remember me telling you “pay for security and compliance is free,” right? Well, maybe if we think a little outside the SAQ box we can use some of these logs to help us stay secure. It certainly is worth exploring.

When do you plan to call the IT members of our team and see if they can help?

(signed)
Your ever-thoughtful consultant / blogger / pain in the PCI

17 June 2008

Merchant Level or SAQ - Which Matters More?

The world of PCI compliance validation changed with the new Self Assessment Questionnaires (SAQ). Here’s why.

Most schools talk about their merchant levels. I hear “We are two Level 3s and 100 Level 4s” or “Our acquirer said we are one Level 4.” Actually, I don’t think merchant level matters much at all; I never have. Oh, if you are a Level 1 it can matter: you have to get a QSA and go through all 240-ish requirements of the PCI Audit Standard. But how many schools are Level 1? So if you are not a Level 1 merchant, move on: you don’t need a QSA to bless your compliance, you self-assess instead. You are done with the Level business; now what matters is which SAQ you use.

The new SAQs are the result of a lot of good work by the PCI Council. They can simplify your compliance validation. They are based on (1) how you take cards and (2) your not retaining cardholder data electronically. That is (except for L1 merchants), they are independent of the number of transactions you process, i.e., merchant level.

You could process a million e-commerce or MOTO transactions a year and qualify for SAQ A (2 pages, 11 questions) if you outsource properly. If you use dial-up POS terminals, you similarly could process a couple of million transactions and qualify for SAQ B (3 pages, 24 questions). And for those using the Internet, you could process almost to your heart’s content and still qualify for SAQ C (6 pages, 32 questions).

How do you do this? If you limit your PCI scope and do not retain cardholder data electronically your validation depends not on merchant levels but on how you process cards. If you choose to retain cardholder data, you can still self-assess, but you have to use SAQ D (28 pages, 226 questions)…not fun.

So does merchant level matter? Only if you are a Level 1, otherwise I’d say “no”…size doesn’t matter. That goes for whether you are a school, a retailer, a hospital, or a restaurant. What does matter is how you take cards and that you limit your PCI scope and not store cardholder data electronically. Let your acquirer do that.

Now your only question is “Which SAQ?”

16 June 2008

PCI Webinar

I have blogged before about how our/your experience in Higher Ed contains lessons for other industries including Retail.

Well, it happened. Somebody actually listened. Sorta scary, isn't it...

Mark your calendars for July 16, and tell your acquirers to listen, too. On that date I'll be doing a 15-minute webinar for the PCI Knowledge Base folks on what banks and retailers can learn from Higher Education. There is a link here to learn more and sign up.

This webinar -- actually, at 30 minutes it is more of a briefing -- comes right after NACUBO's annual meeting where Marc Henkel and I will be presenting on PCI.

Between this, NACUBO, and a couple of weeks back in Tokyo, July is shaping up to be an interesting month.