PCI DSS News and Information for Higher Education

pcAnywhere Users Alert -- Patch Now!

2012-01-25T17:40:00.000-08:00

SANS reports that Symantec has just released a document describing vulnerabilities for pcAnywhere users. You can click here to get details and a link to the document.

I know many campuses use pcAnywhere, and if that includes you and your campus, the advice is simple: patch it NOW!

SANS also reports that someone -- possibly/likely a bad guy -- has started scanning looking for services on port 5631 (used by pcAnywhere). While this is only one incident, the number of places using pcAnywhere is pretty high.

A Suggestion for Your Open Campus PCs

2012-01-18T08:41:00.000-08:00

I was reading the latest news about City College of San Francisco administrators urging students and staff not to use their computers for sensitive purposes like online banking, when I had an idea (also see here for my earlier post). Certainly City College is not the only institution with lots of PCs available for student and staff use but without the means to protect those devices. My guess is everyone reading this blog has a similar situation on their campus.

My idea is simply to post a sign above each one something like the one above. It seems that if the institution cannot stop students from downloading malware (and who can?) or even installing malware intentionally (it could happen), then it makes sense to have some kind of warning for casual users. A good place to start might be to just tell users that if they are visiting a site that requires a password, that site likely contains some personal or financial information they might not want going to the bad guys.

The Web is a dangerous place. Maybe that should be part of everyone's education.

Computer Viruses Stole User Data...for Years

2012-01-13T15:03:00.000-08:00

I saw an article in today's San Francisco Chronicle describing how the computers at City College may have been infected with a number of viruses. The situation is not good. The devices were sending personal data to addresses in Russia, China, and other places, and the IPs in some cases were known criminal operations. You can read about it here, and it is not pretty reading.

It isn't surprising that general purpose workstations are used by students for all kinds of purposes, including research. In visiting a lot of sites and checking assorted social networking sites, the machines can become infected. In many cases, this would be just annoying since the most that any bad guys might get would be your course schedule. But things are not that simple.

Your students (and faculty and staff and ...) also use those machines to do home banking, check credit card accounts, and do all kinds of other stuff where their credentials can be stolen and shipped off to badguys.com. And that appears to be what happened here.

Oh, by the way, it looks like it has been happening for years. That's not a typo. Years. And "tens of thousands of students."

There is a lesson here. PCI requirements for anti-virus and other protections should apply across the board. Users should be warned that the person before them may have inadvertently downloaded a virus or other malware, so don't do anything confidential or financial. We live in a dangerous world, and the Internet is a very dangerous place.

I don't know how all this will work out for City College, which is a fantastic institution. I've taken a few courses there, and the faculty is great. The big thing on this Friday 13th is to learn a lesson about the need to protect the systems your students, faculty, and staff use.

PCI Workshop Agenda is Available

2012-01-13T08:12:00.000-08:00

The Treasury Institute has posted the agenda for the 2012 PCI Workshop on its website. You can click here to view the agenda and/or register. Once again we will begin Monday afternoon with a series of briefings on PCI developments that have a direct impact on Higher Education. The Tuesday sessions are led by your peers from schools nationwide (I'm really looking forward to several in particular). Wednesday will be mostly interactive with our expert panel and the ever-popular Information Sharing session.

Personally, I am very excited about this, the Treasury Institute's seventh (!) multi-day PCI workshop (and ninth PCI workshop overall). I also want to thank all of you who volunteered to join our faculty. I was a bit overwhelmed by the extremely high quality of people and ideas I received. Narrowing down the field to the present list was not easy. Thank you to all who volunteered or helped with agenda topic suggestions.

Please be sure to make plans to join us again in Indianapolis. The dates are April 23-25. We have a reasonably large block of rooms at the hotel, but it might be a good idea not to wait too long as I am expecting another good-sized group this year.

PCI Workshop - Last Call for Speakers!

2012-01-03T10:02:00.000-08:00

I am finalizing the agenda for the upcoming PCI Workshop. I have some interesting schools presenting, and I'm really happy to announce that I have managed to wrangle Mike Dahn as our guest speaker. Mike is a security expert and has been closely involved with PCI DSS since the earliest days. He (together with his partner) developed and led the training for QSAs for several years, so he knows what he is talking about. Mike spoke once before a couple of years ago, and he electrified the audience. I'm sure that this year will be the same. I am also hoping to have the PCI Council back with us again.

But that is only part of the picture.

As most of you know, this is a 3-day workshop -- April 23-25, 2012 -- exclusively for Higher Education. I still need a few speakers to round out the agenda. If you are willing and able to share your experience, please let me know (wconway@403labs.com). Here are some topic areas that you have told me you would like to hear more about:

How do I get my Micros dining system (or hotel operation) compliant?
How can I reduce my campus' PCI scope (changing processes, networks, etc.)?
Where does Voice-over-IP (VOIP) fit, and how does it affect my PCI scope?
What does a dedicated payment workstation look like?
How do other schools allocate costs across departments and secure funding for PCI compliance?
Policies: what have other schools done to develop and implement all the policies required by PCI?
A team presentation: What the business side needs to know about IT; What IT needs to know about the business side. Maybe with two people from different schools!?! Let me know.
Or...just about anything you found important.

In case you need an incentive, how about this: speakers attend the workshop free, and the Treasury Institute pays your hotel expenses. About all you have to do is get yourself there.

The success of the workshop relies on schools sharing their experiences and learning with each other. Please shoot me an email or leave a comment (I moderate them, so I'll see it and it won't be published) and I'll be in touch.

I'll look forward to seeing you in April. Now after you email me with your speaking ideas, get over to the Institute's website and register!

Happy Holidays, and Thank You

2011-12-21T16:25:00.000-08:00

This is a good time to say "thank you," and wish a Happy Holiday and peaceful new year to everyone (both of you) who follows this blog. This has been an interesting year in PCI (we got version 2 rolling) and, unfortunately, information security (for a slide show of the biggest security breaches of the year, click here).

It has also been a great year for the Treasury Institute. We had the biggest PCI Workshop ever in May, and I personally look forward to trying to top that program in 2012 with more great presentations, speakers, and opportunities to network with other schools. I didn't get to attend the annual Treasury Institute Symposium this year, and I won't make this year either (I've already booked for some onsite work), but you should check it out. Charleston should be beautiful.

Personally, it has been the busiest of years. I found myself flying about 100,000 miles (not points, actual miles) this year. That meant I was on the road a lot, and I'm still trying to figure out if my wife thinks this is a good or a bad idea... Somehow, I managed to survive the middle seats, delayed flights, standby anxiety, and TSA security theater. I think next year I'll just buy more caramel corn at the airport to smooth out the travels.

In addition to traveling, I managed to blog more than I ever imagined with posts here, my (almost) weekly column at StorefrontBacktalk.com, and at 403 Labs' own blog. Throw in a week at RSA and really interesting speaking gigs with EDUCAUSE, SACUBO, and a few others, and it was a pretty interesting year.

Thanks to all of you who are clients, thanks to all of you who are not, and thanks to the Treasury Institute for all they do.

See you all in 2012.

The Bad Guys are not Nice Guys

2011-12-16T14:57:00.000-08:00

According to the excellent Krebs on Security website, the Manhattan police have released indictments on 55 people who were part of the gang responsible for a string of identity thefts in New York. The details are disturbing for a couple of reasons.

First, a number of them were associated with financial institutions or a charity. That is where they seem to have gotten some of their information. The ring also included everything from money mules to a UPS driver who is accused of diverting cards.

Another disturbing part is that the people were affiliated with criminal gangs, and two of the people under suspicion turned up murdered during the course of the investigation.

As I and others have said before, the people trying to steal payment card data are sophisticated criminal enterprises. They are not all overseas. Protecting the cardholder data and other personal data entrusted to you is important. Those of you securing your systems and protecting the relationships with your students, parents, alumni/ae, and donors are doing good work. Keep it up!

The bad guys (and they definitely are "bad") are not taking the Holiday off. I heard from one school that they are getting people attempting to donate with a credit card that turns out to be stolen. What is happening is that the "donor" is using the school to check out if a card has been reported lost or stolen yet. If the "gift" goes through, my guess is the next step is to the nearest electronics store or online retailer. Naturally, the donation is charged-back by the rightful card owner, but by then it's too late. The school loses the gift and gets to pay transaction costs on the way.

PCI Council's Open Mic Meeting

2011-12-12T15:01:00.000-08:00

The PCI Council held an "Open Mic" session today for Participating Organizations this morning. Here are some of the highlights.

A major focus was soliciting feedback on the both PCI DSS and PA-DSS. Each PO (and this includes NACUBO, so get us your feedback!) can make up to five comments or requests for clarification/change to the standards. The deadline to submit feedback is April 1. Tom Davis and I will be tracking ideas, and we will provide feedback in time.
There was review of the three Special Interest Groups (SIGs) for 2012: Risk Analysis, Cloud Computing, and eCommerce for Level 3 and 4 merchants. Since the eCommerce SIG has the greatest potential benefit for Higher Ed institutions, I joined that SIG. I am looking forward to participating actively and developing some good guidance that will benefit institutions of all sizes. If your school is a PO, it's never too late to join a SIG...I'd welcome the company!
Training continues to be a Council priority. There will be two webinars addressing training sessions and schedules early in the new year (January 26 and 31).
We can expect to see some more guidance on mobile computing in 2012.
We might also see some additional guidance on tokenization. I got the feeling the Council felt that the current documentation was enough, but they would do more based on what they see early in the new year.
Lastly, Bob Russo (General Manager of the Council) acknowledged the increased interest in skimming at the POS (see a previous post, here). Bob's advice was that the best defense against skimming is vigilance by front line staff spotting changes or differences. He also pointed out that the Council has an excellent document addressing skimming (click here to download a copy). He noted that it was among the most frequently downloaded documents on the site (and deservedly so, IMO!).

There is a second session scheduled for Wednesday, and the recording of each session should on the Council's website soon. I believe they will be generally available if you want to listen.

Top 25 Security Influencers

2011-12-07T08:15:00.001-08:00

This morning I saw an interesting list of the Top 25 Influencers in Security You Should be Following put out by Tripwire. It is not a complete list, but it has some really good names there. I follow a number of them, and I actually know a few of them well enough that we talk, email, and occasionally even meet up face-to-face.

I suggest you check your list of blogs or your Google Reader (or whatever reader you might use) and see if you want to add some of the blogs from these people. My own personal list of security blogs, of course, is on the right...you can see it, just over there under the Walt's Recommended Blogs list. Your list will vary depending on your own interests, but as you do your end-of-year cleanup, you might want to update your list with some of these from Tripwire.

PCI Council Open Mic Sessions

2011-12-06T15:29:00.000-08:00

The PCI Council will hold two Open Mic sessions, December 12 and 14th. If your institution is a Participating Organization, you should have received an email invitation with instructions on how to register for a session. Since the Council's email contained a registration code, I assume the sessions are restricted to POs only.

Since NACUBO (in conjunction with the Treasury Institute) is a PO, I plan to attend the December 12th session. I'll report on particularly interesting comments or outcomes here as appropriate.

ACH email Scams May Be a Teachable Moment

2011-12-02T07:52:00.000-08:00

Have you received any of those "Your ACH has failed" or "NACHA Transaction Alert" emails in the past few weeks. I have, and I deleted them immediately. I did that because they are spam.

If you received these emails, then you noticed they were very brief. They also contained a link or downloadable file, which I really, really hope you didn't click.

The good news is that these emails are a teachable moment. My colleague, Morgan Tremper (he runs our scanning support group and is a general security whiz) wrote a good piece at the 403 Labs blog (you can click here to read it). He says it better than I, so I won't repeat his thoughtful analysis.

My point is that in this season of endless appeals for our generosity, it may be a good time to alert all your staff that it is no time to go clicking on ANYTHING in an email they were not expecting.

Call me a Grinch if you like, but I'd rather be a safe Grinch than Pwned. That is not a very good holiday gift, either.

Protect Your POS Devices, NOW

2011-12-02T07:27:00.000-08:00

Just because you are a Higher Ed institution does not mean the bad guys have not targeted you. Unfortunately, the University of California Riverside just found that out. In a news release the school advises that campus cash registers at food service locations were compromised, and that up to 5,000 individual card numbers may have been compromised. These cards didn't just belong to students, but may have included parents and visitors, too.

I don't have any specific information on this breach other than what is in the release. What they do say, though, is disturbing: "The hacker had unauthorized access to card numbers, cardholder names, card expiration dates and an encrypted version of debit card pin numbers [sic]."

Attacks -- both physical attacks on POS like skimming (as I wrote about here) and "cyberattacks" on Web-facing systems -- increasingly target smaller businesses like higher education. Why? The reason seems to be because smaller businesses have poor security or none at all.

You do not want to have to go to your president to ask for budget (to set up a website, field calls, write a FAQ, etc.) and approve a press release telling your students, parents, alums, and friends to "monitor card activity carefully, and report any suspicious activity."

Protecting the POS should be part of your annual security training. The bad guys are out there. They target higher ed institutions. And if you are compromised, please know you cannot expect any special treatment from the card brands as far as fines or other penalties. You are a merchant, and you lost the data. Game over.

SIGs for 2012

2011-11-21T14:34:00.000-08:00

The votes are in, and the three Special Interest Groups for 2012 are:

Cloud
eCommerce Security
Risk Assessment.

The selection of eCommerce Security is very good news for all Higher Ed institutions (see previous post here). I ranked the eCommerce SIG as the top priority for Higher Ed, so it is good to see it on the list. Now we should get some detailed guidance on how best to implement hosted order pages, shopping carts, and dedicated payment workstations.

PCI 2.0 Comment Period Now Open

2011-11-01T14:55:00.000-07:00

Hard as it may be to believe, PCI 2.0 is no longer all that "new." In fact, starting today, November 1, the official comment period is now open. That means I want to hear from you on your experiences with PCI 2.0.

Both PCI DSS and PA-DSS have a three-year lifecycle. It has now been one year since both standards were aligned and version 2.0 became effective at the start of 2011. That means we are entering the comment phase where your experiences are important. Keep in mind that while the version has a three-year lifecycle, there are provisions for regular updates to reflect the experience of merchants, service provider, and vendors.

NACUBO, in partnership with the Treasury Institute, is a Participating Organization (PO) in the PCI Council. Tom Davis of Indiana University and I represent NACUBO - and by inference you - at Council meetings and deliberations. Therefore we want to hear what your experiences have been with PCI 2.0 so we can assemble our comments and get them to the Council.

There are a couple of things to understand. First, NACUBO gets to make five comments. That is, we can request clarification or changes or whatever to five PCI requirements. Tom is working the EDUCAUSE angle, and I am asking for comments through the Institute's blog. Maybe somebody can even post something on the PCI listserve? (hint, hint.)

I would like to ask you to organize your thoughts, experiences, and feedback on PCI 2.0. You can send comments directly either to me (wconway@403labs.com) or Tom (tdavis@iu.edu). If your school is already a Participating Organization, then be sure to get your whole PCI team together and have your voice heard. After all, that is one of the reasons you are paying to be involved in the Council.

Both of us, along with NACUBO and the Treasury Institute, look forward to receiving your comments.

Straight Talk on Tokenization

2011-10-31T22:15:00.000-07:00

Are you looking at tokenization as a way to reduce your PCI scope? My guess is that you or at least some of your campus merchants are, and therefore you will want to be as up-to-date as you can especially with the recent PCI Council guidance on tokenization and PCI scoping.

Many campus merchants are considering various tokenization strategies (or at least their software and service providers are pitching tokenization to them). As I've written before (see here, and here), tokenization has a lot of benefits. It also has some things you need to be careful of, and definitely some things you need to know before you go signing any contracts with token providers.

On Thursday, November 3 I will be participating in a tokenization webinar entitled: Straight Talk on the New PCI Tokenization Guidelines -- A QSA's Viewpoint. The webinar is sponsored by Intel (which also sponsored some of my tokenization research and the Tokenization Buyer's Guide). I will discuss tokenization in general, some of the different approaches, and which implementation might be best for which types of merchants.

If you are interested, you can register using this link. Yes, there will be a description of (i.e., pitch for) Intel's product offering at the end, but the majority (my part) is vendor agnostic and explores both third-party hosted and internal solutions.

If you are considering tokenization, you may want to have a listen. If you can't make the live webinar, I'm guessing they will have a recording available.

PCI Council Webinar to Address Point-to-Point Encryption Security

2011-10-28T16:18:00.000-07:00

The PCI Security Standards Council has announced will provide a detailed overview to the recent updates to the PIN Transaction Security (PTS) program on November 8. A second, repeat webinar will be November 10.

Schools interested in P2PE may want to consider attending to get the latest information on the latest release of the PCI PTS requirements. Many institutions and their auxiliaries are very interested in this exciting technology that can reduce your PCI scope greatly. There are still some details like testing the POS devices to make sure they work as advertised, and this webinar should address some of those security questions.

Here are the details. You can also check out the PCI Council’s Website link:

PIN Transaction Security Program Updates: PTS 3.1 and PCI PIN Security Requirements 1.0

Tuesday, November 8, 2011 at noon PT/3:00 pm ET/8:00 pm GMT 

Thursday, November 10, 2011 at 8:00 am PT/11:00 am ET/4:00 pm GMT

Please join members of the PCI Standards team for a detailed overview of the newest updates to the PIN Transaction Security (PTS) program, followed by a live Q&A session. The presentation will cover key changes to PTS requirements including:

• Updates to PTS Point of Interaction (POI) Requirements 3.1 that include two new approval classes for Secure Card Readers and Non-PIN Entry Devices

• Extension of Secure Reading and Exchange of Data (SRED) and Open Protocol (OP) modules to version 2 devices

• Explanation of how these changes can facilitate the secure deployment of point-to-point encryption (P2PE) technology and mobile payments

• Overview of PCI PIN Security Requirements 1.0 and the use of this criteria for the protection of PIN data enhancements to HSM Security Requirements

I have written about P2PE before on this blog (click here to read it). Those of you new to this may want to have a read before the webinar.

Voting for PCI Special Interest Groups is Open

2011-10-25T08:17:00.000-07:00

I know a number of your institutions are Participating Organizations (POs) in the PCI Council. If you are, it is time you get your PCI team -- including business and IT groups -- together to decide how to cast your vote for the Special Interest Groups (SIGs) for 2012.

The Council received 31 nominations for SIGs, and they narrowed it down to seven. Based on how POs vote, three will be selected for 2012. The seven are (in no particular order):

Managing administrative access to systems and devices
Preparing a risk assessment
Patch management
eCommerce security
Cloud technology
PCI for small businesses
Managing hosted service providers.

Looking at the seven, four are more technical in nature and three are business focused. That is why I suggest you want to get your whole team together so you gather ideas from all over the institution.

As most of you know, I (along with Tom Davis of Indiana University) represent NACUBO which is a PO. We finished our analysis and have recommended NACUBO's vote (which I'm casting later today) to reflect the mix of needs of Higher Ed institutions of all sizes. You now need to do the same for your institution. Voting opened Monday (Oct 24) and closes November 3, so don't wait!

Schools that are POs were sent an email last week with a link to the Council's PO portal. The portal has videos of the brief presentations from the Community Meeting where they previewed each nominated SIG. I recommend you view the videos, discuss your priorities, and cast your vote.

Not many standards or regulatory organizations let their 'constituents' decide where to do research and provide guidance. The PCI Council does, so I hope all schools who are POs will be sure and vote.

Self-Assess Like a QSA?

2011-09-21T07:25:00.000-07:00

Just about everyone reading this self-assesses their institution's PCI compliance using one or a set of Self-Assessment Questionnaires (SAQs). This is the PCI Council's -- and the card brands' -- own version of the honor system.

But the very largest Level 1 merchants don't get to use the honor system. Instead they must get an outside assessment, either by a Qualified Security Assessor (QSA, like me) or a member of their own staff who attended training and qualified as an Internal Security Assessor (ISA).

The QSA prepares a Report on Compliance (ROC, pronounced "rock"). This covers all of PCI. Moreover, the QSA needs to see multiple pieces of evidence before she/he can mark a requirement as "in place." The Council has released its updated guidance on just what the QSA does. It could make informative reading. It is now available for everyone to see.

Click here to download a copy of the ROC Reporting Instructions, then see how your own internal self-assessment measures up.

Staying in Touch With Developments

2011-09-20T21:15:00.001-07:00

I'm getting ready to head off on vacation for a few weeks, and it has me thinking about staying in touch. I mention this because I probably won't be making many blog posts for a bit, and at the same time there is a lot happening in the PCI world that you want to make sure you stay current.

One way is to set up your Google (or Safari or whatever) reader and load up the RSS feeds for your favorite blogs. That is what I do, and it's great for filtering what you need to see. A great way to start is with the blogroll on the right. These are some of the blogs I follow (or participate in), and I'd add them to whatever list you put together.

Of particular interest might be the StorefrontBacktalk link. While they have gone to a premium pricing model (hey...everybody's got to eat!), I am pleased to announce that my PCI columns shortly will all be "free." There is a lot of other great retail content there, too, so if you have auxiliaries or other retail-like operations on campus, I'd point your RSS feed there.

With so much happening on point-to-point encryption (with the painful acronym P2PE), tokenization, and the reality of PCI 2.0, you should take a few minutes to skim the highlights so you can stay up to date with what's happening.

Over the next few weeks, I'll be relying on my iPad and assorted English, Belgian, and French hotel WiFi links to stay connected. Yes, I'll still be on vacation, but I'll also be staying in touch. You may want to do the same.

Certificate Attacks on Google

2011-09-02T16:38:00.000-07:00

Like many of you involved in security, I have been following the recent news about the recent compromise of a Dutch certificate authority (presumably by the government of Iran, but not proven). There was a brief piece earlier in the New York Times (click here). You also can find a great explanation and exposition of exactly what happened and what it means in this blog post.

Yes, the Internet is a very scary place.

UPDATE:

Here are some additional articles that shed some more light on the risks and what you need to know:

If you read nothing else, please read this post (click here) from my colleague, Morgan Tremper. As he says, "Far and away, the most essential method for staying ahead of threats to your security is fixing the problems that the industry already knows about." A very clever man is our Morgan. What Morgan points out is that there is something you can do to protect yourself, but you (and all your users) have to *do* it!

"The disturbingly complete compromise of DigiNotar, the Dutch certificate authority, has broad ramifications for other CAs, enterprises and consumers who rely on the shaky web of trust that comprises the CA system. Here's what you should know about the attack and what you can do to protect yourself against intrusions resulting from it." (Click here to read more) .

"The details of the attack on DigiNotar that began to leak out on Monday have gotten uglier by the day as more and more researchers have looked into the compromise and the depth of the problem became clear." (Click here to read more).

Happy reading on this holiday weekend.

PCI Tokenization Buyer's Guide Available

2011-08-26T13:05:00.000-07:00

I am very pleased and excited to tell you about a project I just completed. That project was to write a buyer's guide for tokenization. The project was sponsored by Intel Corporation. While they got to look at the draft, I (and my colleagues at 403 Labs) had complete editorial independence and control. The result is a vendor-neutral, technology-neutral discussion of tokenization, how it might reduce your PCI scope, how to evaluate alternative vendor products, and what you can expect.

Together with the guidance from the PCI Council, I hope this Buyer's Guide will help merchants determine if tokenization is right for them, and if it is how they should evaluate their options. If your bookstore, food service operation, parking garages, or other auxiliary organization has any retail-type payment activities, they likely are (or should) be looking at tokenization as a way to reduce their PCI scope. This guide was designed for them.

You can download a pdf of the white paper at Intel's website. I hope you find it useful.

Visa on How to Detect a Security Breach

2011-08-22T15:01:00.000-07:00

Visa just released a very interesting slide deck entitled Identifying and Detecting Security Breaches. You can see it by clicking here. The presentation illustrates some of the signs of a potential incident among other things.

The presentation makes interesting reading, and you may want to read it along side your own incident response plan.

I particularly like the emphasis on logs and logging. Having a good logging system is critical to detecting security breaches, and Visa emphasizes this point. They also discuss the basics of incident response management (which is why you may want your own plan nearby).

I suggest you download the material, and while your at it, surf over to Visa's website and download their excellent What to Do If Compromised document. I always send a copy to clients before starting a new engagement.

PCI DSS Point-to-Point Encryption Guidance Soon?

2011-08-22T11:06:00.001-07:00

Like many of you, I am looking forward to the PCI Council's guidance on point-to-point encryption. A lot of schools are talking to vendors about POS devices that promise to take their systems out of scope. Some schools are buying these terminals, and I have to admit they seem attractive. Before you go too far, though, I recommend you take a look at what the Council is saying, and what they might say, about how P2PE (the unfortunate acronym) can reduce your PCI scope.

The place to begin is to download the excellent "Initial Roadmap: Point-to Point Encryption Technology and PCI DSS Compliance v 1.0." This document came out last October. It lays out a lot of the details and what to look for in a P2PE system. What we are all eagerly awaiting, though, is the follow-on document promised before the end of this year: the actual "Validation Requirements for Point-to-Point Encryption." The Council promises:

It [the Validation Requirements] will define requirements and the process for validating effective P2PE solutions. Its intended audience is vendors, assessors, and labs that may evaluate the testing procedures associated with key management, segregation of duties, access controls, and other necessary criteria.

Here are some things to keep in mind as you look at solutions in the market today.

First, please understand P2PE only affects the transmission of cardholder data. It says nothing about storage or processing. The Roadmap document makes this clear in several places. Second, keep in mind that this is an integrated hardware-software-provider solution, and all three parts have to work for it to be effective.

Then look at the advice on how to implement the system:

Encryption is performed immediately after reading the data through contact-based (EMV), magnetic stripe, contactless, PAN key entry or Near Field Communication [NFC] methods.
The portions of the merchant environment that no longer require validation have no access to: plaintext CHD, cryptographic keys, or a decryption function that would allow encrypted data to be decrypted.
CHD (including any sensitive authentication data) cannot be decrypted until received by a validated decryption point such as a segmented portion of the merchant network or processor/acquirer network.
P2PE solutions including devices, key management practices, and encryption and decryption environments are independently validated.

The Roadmap has four conclusions: the technology is immature (meaning don't necessarily believe everything you might be promised); P2PE can move only the transmission part of your transactions out of scope (if properly implemented and validated, of course), meaning your payment application may still be in scope depending on where the two "points" are; P2PE does not make PCI DSS compliance go away (i.e., silver bullets are still outlawed); and you need independent validation of the P2PE solution, particularly the encryption/decryption process.

It is this last part where I expect to see the Council announce a program modeled on PCI PTS. That is, there will be independent testing labs that will validate devices (and their underlying software) for compliance, much like they test encrypting PIN devices today. This will give vendors a clear path to get their devices approved, and it will give you confidence that what you buy and install will reduce your PCI scope.

Let me make it clear I have no inside information. I am not part of the task force, and I have no insights into the Council's deliberations. However I do expect a guidance document to be issued soon (it is getting late in 2011, after all).

P2PE is an exciting and promising technology to reduce PCI scope for many merchants operating in a card-present environment. Like tokenization, there will be lots of issues to address in any implementation. In the meantime, if you have any interest in point-to-point encryption (and I expect almost all of you dear readers will), download the Roadmap and read it carefully. It may help you with your intermediate decisions, and it will help you understand the final guidance document when it comes out.

I'm Here For Another Year

2011-08-16T13:53:00.000-07:00

Earlier this month I took my annual QSA re-training and then the re-qualification exam to continue being a QSA (for my third year). For those of you who don't know, the PCI Council requires all QSAs to go through this process each year. The good news is it looks like I'll keep doing this for a while.

The re-qualification training has changed quite a bit. It is computer-based, and it has improved each year. This year there was a lot of focus on PCI version 2.0 changes as well as the supplementary guidelines issued by the Council. The refresher on the actual PCI DSS Requirements was pretty cursory, as you would imagine for a current QSA, but there was some additional material that was quite well done.

The test was a series of multiple choice questions on everything PCI and payment cards. My biggest problem was arguing with the test because I could make a case in a couple of instances that several answers were true. I know talking back to a computerized test is neither very useful nor productive, but I felt better. All of which is to say I likely didn't score 100%.

I'm looking forward to another year of blogging, working with my clients, and definitely another year of the Treasury Institute's PCI Workshop. I hope to see many of you there next April.

Passwords Don't Have To Be That Hard

2011-08-15T16:55:00.001-07:00

One of the issues that most frustrate users is passwords. They have to be long, they have to be complex (i.e., upper and lower case, numbers, symbols), and they have to be changed regularly. PCI Requirement 8 has an amazing number of detailed requirements for passwords.

So how do you enforce a compliant password policy without everyone either (a) writing their passwords on yellow sticky notes attached to their screens, or (b) threatening you when you show your face in their office? Here are some thoughts.

Personally, I use 1Password to manage my (strong) passwords. There are also various other programs, many of which are free. I just like that one (along with a lot of other security pros for whom I have a lot of respect).

I saw this article a while ago in the New York Times. The author contends:

MAKE your password strong, with a unique jumble of letters, numbers and punctuation marks. But memorize it — never write it down. And, oh yes, change it every few months.

These instructions are supposed to protect us. But they don’t.

Part of the reason is that it is tough to follow those instructions.

But there are other approaches. For example, please take a look at this great column from the New York Times. The author emphasizes that it is the length that is important in passwords:

Here’s a little quiz: Which is the stronger password? “PrXyc.N54” or “D0g!!!!!!!”?
The first one, with nine characters, is a beaut. Mr. Gibson’s page says that it would take a hacker 2.43 months to go through every nine-character combination offline, at the rate of a hundred billion guesses a second. The second one, however, is 10 characters. That one extra character makes it much, much stronger: it would take 19.24 years at the hundred-billion-guesses-a-second rate. (Security researchers have established the feasibility of achieving these speeds with fairly inexpensive hardware.)
Don’t worry about the apparent resemblance of “D0g,” with a zero in the middle, to the word in the dictionary. That doesn’t matter, “because the attacker is totally blind to the way your passwords look,” Mr. Gibson writes on his Web site.

Wowsers. If I can remember the number of exclamation points (or ^s or &s or whatever), then I can have a strong password that I might be able to have users remember.

But for genuine wisdom (and I do not use that term lightly!), you have to see the blog post by my colleague Jeff Zellman at the 403 Labs blog. He writes:

What many people fail to realize is password cracking is done by automated computer programs. These programs are fairly sophisticated and try all the characters on the keyboard (not just letters!). Shorter passwords are easier to guess since there are less characters to match. Just like a 3-ball lottery is easier to win than a 7-ball one.

Now imagine the difficulty of winning a 44-ball lottery.

You actually have to see the accompanying cartoon (talk about wisdom!) to get it, but the point is that we can help users create strong passwords (high entropy) using passphrases that they can remember.

Computers can crack passwords (eventually), but people have to remember them. Too often when we are working on PCI compliance we forget that humans have to implement the requirements or they won't stick. Passwords are no different.

Let's see... "correct horse battery staple"... Read Jeff's post and you'll get it.

Maybe your users will, too.

Tokenization Guidelines Released

2011-08-13T17:16:00.000-07:00

Friday, the PCI Security Standards Council released it long-awaited tokenization guidelines. You can click here to get a copy.

I wrote about it on the 403 Labs blog , so I won't repeat myself. Also, Evan Schuman did a great job summarizing the implications on StorefrontBacktalk.

If you are contemplating tokenization at all, do yourself a favor and download and read carefully the Council's guidelines (along with the blog posts above). Especially see the very end of the guidelines where they talk about "high value tokens." In a lot of cases, your tokens might be these "high value" ones, and if so, they may be in scope for PCI...!

Visa Supports EMV Cards - Can You Skip PCI Revalidation?

2011-08-11T08:36:00.000-07:00

The two thoughts in the headline. While they might seem to be unrelated, actually are part of the same idea.

In case you missed it, Visa released four (!) bulletins on Tuesday about their plans to accelerate the acceptance of chip technology for both card and mobile device transactions. What follows is a brief discussion of each of the releases, links to the original docs, and a few editorial comments (as if you had to ask...).

The first bulletin describes Visa's plans to "accelerate the migration to contact and contactless EMV [named after the three organizations behind the standard: Eurocard, MasterCard, and Visa] chip technology in the United States." It is a great overview of Visa's strategy, explains the technology a bit, and links to the following three bulletins.

In a second bulletin, Visa describes the details, particularly incentives for merchants to upgrade their POS devices to process chip transactions. The carrot: "Visa will waive Payment Card Industry Data Security Standard (PCI DSS) compliance validation requirements to encourage merchant investment in contact and contactless chip payment terminals."

Wowsers...did Visa just say they were waiving PCI compliance!?! No, the did not say that. What Visa said was that effective October 2012, if a merchant (1) had validated its compliance in the last 12 months, (2) didn't store sensitive authentication data (like the security codes or mag stripe), (3) was not involved in a cardholder data breach, AND (4) processed at least 75% of their transactions on "dual-interface EMV chip-enabled terminals", they could participate in the Technology Innovation Program (TIP).

Under TIP, the merchant does not need to RE-VALIDATE compliance each year. You still have to be compliant, and if you get breached the same penalties presumably will apply, but you don't have to re-validate your PCI compliance.

This TIP program (already available in Europe) is what has lots of people buzzing. What does it mean for Higher Ed? I've got some thoughts (naturally!), and they are a bit further down.

Who ever heard of a carrot without a stick? Certainly not Visa, and the "stick" is in a third bulletin. This one describes a liability shift. Simply put, after October 2015 (note the different date) the rules for who is responsible for POS fraud shifts: "This policy assigns liability for counterfeit fraud to the party that has not [Visa's emphasis] made the investment in EMV chip cards (issuers) or terminals (merchants' acquirers)."

Many observers and blogs are missing this liability shift. Read it carefully. It looks to me like Visa wants everybody in the US to have a chip card by 2015.

Therefore, if a merchant and/or acquirer (or processor) doesn't buy POS terminals and upgrade their back office systems to process chip transactions, they eat any and all POS fraud.

The fourth bulletin is the acquirer/processor mandate, and it mainly contains technical details on Field 55 and other message elements.

What does this mean for Higher Ed? Should you go out and start pricing EMV chip-enabled POS terminals for everybody? Do you have to? How much will TIP save you if you qualify?

Good questions all. First some full disclosure: I am a QSA, so I might be biased in some of this; also I used to work for Visa, and those were some of the happiest years of my professional life, so again I might be biased. Given all that, here are some thoughts to get us started...

Kudos to Visa for showing leadership. The US is far behind the rest of the world in terms of card technology. As a cardholder I applaud what they are doing. Even if fewer companies need QSAs, I'm willing to start polishing my resume. Besides, nobody waived PCI compliance, just the formal re-validation (once you have validated). I hope I don't have to wait until 2015 to get my chip card.

Will the other brands follow suit? When will we see MasterCard's, Amex', or Discover's chip acceleration plan? If they don't, any benefit from TIP will be reduced to about zero since those brands will still require PCI compliance re-validation.

Speaking of a carrot...what carrot!?! I don't see how anyone but the biggest (Level 1 and some Level 2) merchants get any benefit from TIP. Smaller merchants don't hire QSAs to prepare a Report on Compliance (ROC), they hire QSAs as consultants. So not requiring one is no big deal. Also, in the past the card brands offered incentive (i.e., lower) interchange rates to offset the cost of merchant technology investment mandates. Here, there is no incentive. Think about it: the card brands introduce a "tax" on all merchants called PCI compliance; one brand then offers to waive the tax if you spend money on technology. To me, that's just giving you back your own money. TIP seems to cost Visa and its issuers not a penny.

Doesn't waiving PCI compliance re-validation hurt security? Visa said their objective was increasing security by encouraging chip technology. I think we have to wait and see if waiving formal compliance re-validation causes merchants to get lazy and backpedal on security.

What about MOTO and ecommerce? Good question. These announcements only dealt with POS transactions. As far as I can tell, chip cards won't help much when the card isn't present. Plus, remember the cards still have mag stripes.

What does this mean for Higher Ed? My guess is it means very little in terms of incentives. However it does mean that you need to have the "dual-interface EMV chip-enabled" POS devices at least by October 2015. It might be time to talk to your acquirer/processor and look at your technology budgets. Then again, if you don't have much POS fraud, maybe you can skate along for a while. I wouldn't advise it, but...

For a great post and discussion, surf over to Securosis and have a read.

Don't Miss Patch Tuesday

2011-08-09T14:02:00.000-07:00

Microsoft released quite a package of thirteen security patches today. You can check out the list at SANS (click here) and here's a link to Microsoft's Technical Bulletin.

This update has some patches you don't want to miss, particularly to Internet Explorer as well as your DNS servers. The IE patches are particularly important as there are known exploits available and in the wild.

Data Breaches are Real

2011-07-21T17:16:00.000-07:00

Your campus merchants are ripe targets of opportunity for hackers and phishers.

If you haven't seen this article in the Wall Street Journal online, I recommend you read it. It is about a small business that downloaded some malware (very easy to do; very tough to eliminate once you do), and as a result they suffered a major data breach. Well, maybe not "major" in the sense of making the headlines, but it nearly put one small business out of business.

The moral of the story is simple: this could happen to you...to your campus...to your auxiliary organizations like parking or bookstore or any other campus merchant.

Please give a thought to passing this link to your campus merchants. I'd also suggest you make stories like this a part of your security training.

The bad guys are increasingly targeting small and medium sized businesses. With the typical open networks and varying degrees of security on most campuses, you should consider yourself at risk every day. Which reminds me, have you taken a look at your latest vulnerability scans? When was the last time you updated anti-virus and installed patches on ALL your systems?

Please don't be the next one in a headline. It'll surely ruin your day.

Credit Card History

2011-07-11T15:23:00.000-07:00

I'll admit it: I am a credit card junkie. For others similarly afflicted or those who might want to see what it is like, take a look at a post at MSN Money on "18 Fun Facts about Credit Cards". There is nothing new here, but it is a good collection of some historic milestones in the plastic payment business.

Higher Ed Credit Card Agreements

2011-07-11T15:07:00.000-07:00

Does your school have a co-brand credit card agreement? Usually, it will be your Alumni Association, Foundation, or even the Athletics or an academic department that has partnered with a bank to issue one of these co-branded cards. If you have one of these, you may want to compare your program with your peers. Thanks to the Federal Reserve and the Credit CARD Act, this is possible.

The Federal Reserve has released its second "Report on College Credit Card Agreements." A copy is available for download at the Fed's site (click here to download a pdf version).

By way of background:

Section 305 of the Credit CARD Act and the Board’s implementing regulations, 12 C.F.R. § 226.57(d), require credit card issuers to submit to the Board each year a copy of any college credit card agreement between the issuer and an institution of higher education or an alumni organization or foundation affiliated with an institution of higher educa- tion (an “affiliated organization”) that was in effect at any time during the preceding calendar year. Issuers also are required to submit the following informa- tion with respect to each agreement: (1) the number of credit card accounts opened pursuant to the agreement (“college credit card accounts”) that were
open at year-end (regardless of when the account was opened); (2) the amount of payments made by the issuer to the institution or organization during the year;2 and (3) the number of new college credit card accounts that were opened during the year.

Issuers were required to make their second annual submission to the Board by March 31, 2011. This submission comprised college credit card agreements to which the issuer was a party during 2010 and information regarding payments and accounts as of December 31, 2010.

The document mainly contains tables of individual Higher Ed institutions' programs, but there is some text and lots of footnotes. There is also an online database of the agreements.

Compliments to the folks at Payments News for pointing out this information.

Mobile Payments Update from PCI Council

2011-06-24T13:07:00.000-07:00

The PCI Council has released their plans for PA-DSS validation for mobile commerce applications. In an announcement to Participating Organizations, they stated:

In November 2010 the Council announced that it would no longer accept mobile payment acceptance applications for PA-DSS review or validation until a thorough review was completed. Understandably, this was met by mixed reactions in the industry. While some applauded the decision - recognizing the very real complexity and security concerns these applications present - many of you eager to take advantage of the benefits of mobile payment processing, were frustrated as to why this step was taken.

This was the first and necessary step that has allowed us to confidently give you clear direction now as to what types of applications can allow you to accept and process payments securely and support PCI compliance.

[Friday] the Council will publish an updated statement on PA-DSS and mobile payment acceptance applications, accompanied by a fact sheet designed to help in identifying and determining which payment applications can be reviewed and validated by the Council as secure for accepting and processing cardholder data and support merchant PCI DSS efforts.

In evaluating these applications in light of our standards, we've determined that the major risk is the environment that application operates within, and whether or not it can it support a merchant's PCI DSS security efforts. Based on this evaluation, we've now identified the types of solutions that can meet PA-DSS requirements and support a PCI DSS compliant environment.

We've also determined the area where solutions can't currently meet PCI requirements - and now we are looking at this closer to see if and how these can be secured, collaborating with industry subject matter experts to produce additional guidance by the end of the year.

We recognize that you have been eagerly awaiting an update from the PCI Security Standards Council on how you can be sure the mobile payment applications you're deploying can accept and process payment cards securely, and we hope you'll take advantage of this first step with these resources today.

You can download a copy of the release by clicking here.

The good news is that for new mobile payment applications for their Category 1 (using PCI PTS devices) and Category 2 ("bundled" hardware and software devices), the door for PA-DSS validation is open. Unfortunately, I'd plan on about a year before there are PA-DSS versions of apps to run on your smartphones.

Meantime, another realistic option is to go for a hardware solution. This is in two parts. First, you will need a secure, likely PTS-listed device to read the mag stripe on the cards. This could be a "sled" or a Square-like plug-in attachment. Then (here's the big part) using the guidance expected soon on point-to-point encryption, a vendor can combine the device with encryption to take the phone itself out of scope. While the merchant won't have the functionality of a full payment app (which is what everyone really wants), they will be able to take cards securely using a mobile device.

There will be more developments in the coming months. Stay tuned...

How Good is Your HR Policy?

2011-06-22T21:19:00.001-07:00

The second part of the headline is: "...and Why You Should Care."

What I'm talking about is what happens when you dismiss someone or they decide to leave? How long does it take your HR and IT departments to cancel their user IDs and privileges?

PCI actually has a bit to say about your procedures, and even if you fill out a simplifed SAQ, you should take a look. For example, Requirement 3.5.6 says that if the employee who leaves happens to be an encryption key custodian, you change your encryption key(s). It sounds pretty simple and obvious when you think about it, but will you know of this rather important detail when that happens? Does HR? Does IT know to tell HR (or vice versa)?

Then again, there is our old friend 8.5.4 which requires you to revoke immediately (the Council splits that infinitive, but ...) the password of any terminated employee. But what does "immediately" mean? To me, it means certainly no later than close of business the employee's last day. If you want a classic example of what can happen, you might want to check out this post from SANS.

You may want to terminate the user's ID the day before when the termination is "for cause." And it may be a good idea either to terminate privileges two-weeks (or whenever notice is received) in advance for an employee who is leaving voluntarily. In this last case, you might at least restrict severely the permissions the employee has.

In these difficult times, it makes sense to look all aspects of where PCI can protect your institution.

How the Stolen Card Market Works

2011-06-17T17:41:00.001-07:00

There were a couple of interesting reports on NPR today. Each covers much of the same ground, but they provide some interesting background for all of us in the card business.

Here are a couple of links:

How to Buy a Stolen Credit Card

The FBI Agent who Broke the Black Market

Also, here is a podcast from PlanetMoney with Keith Mularski (same guy) on dark market and the how credit cards get stolen and fenced.

The bad guys are out there. They go for credit cards because (of course) that's where the money is.

PCI Virtualization Guidance Published

2011-06-13T09:59:00.000-07:00

The PCI Council's Virtualization Special Interest Group (SIG) just released their report. You can download it here.

I'd recommend it to any school looking at or implementing virtualization in their PCI network.

News From the PCI Council

2011-06-02T18:19:00.000-07:00

As all of you know (I hope), NACUBO is a Participating Organization with the PCI Security Standards Council. As NACUBO's representative, I get a periodic newsletter from the Council with updates and news. Often, these newsletters are pretty dull, but the current one has some interesting information I -- in my role as your representative to the PCI Council -- want to share with you.

There is good news (I hope) for all of you looking at virtualization as potential technology that can make PCI compliance easier and less costly. The good news is that the Virtualization Special Interest Group has delivered its report, and the Council will be releasing it soon. Here are some details from the newsletter:

I know you've all been eager for the Council to release the findings of the Virtualization Special Interest Group (SIG). Thanks to their hard work and collaboration with the Council's Technical Working Group, guidance on the use of virtualization in accordance with the Payment Card Industry Data Security Standard (PCI DSS) will be released this month! We'll be hosting a webinar at the end of June to provide greater detail on the information supplement and address your questions.

To register for the Tuesday, June 28th session, click here.

To register for the Thursday, June 30th session, click here.

Another piece of good news is that the Prioritized Approach 2.0 (to match PCI DSS v 2.0) has been released. There are some good improvements in this version. If you are interested in this or if you wish to use it with the current version of PCI DSS, you can download a copy at the PCI Council's website.

The Council is offering a range of PCI training options. You can view the schedule (and pricing) for their instructor-led and online PCI training courses here. I guess I'd be remiss if I didn't also mention the Treasury Institute's own PCI training. The two are different: the Council focuses on the PCI DSS itself, where the Institute's workshops emphasize hands-on case studies of what other schools have done to become compliant (along with a PCI briefing). The training sessions are complimentary, so even if you have been to the Treasury Institute workshops, it may make sense to check out the Council's offerings.

Lastly, for all you PCI fanboys, you now can follow the comings and goings of the world of PCI on LinkedIn. Click here to follow the Council.

Visa Chargeback Publication: More than Meets the Eye

2011-05-26T14:28:00.000-07:00

I recommend every one of you who is responsible for payments, card processing, PCI for your campus download a copy of Visa's Chargeback Management Guidelines for Merchants (click here). It's a long pdf, but it is worthwhile.

Here are some of my favorite parts, and you'll notice this document (which I first learned about from Branden Williams' excellent blog) has a lot more than just Chargebacks. Actually, it's a pretty good primer on payment cards.

Starting on page 10 is a great "Payment Card 101" that describes how a credit or debit card transaction flows through the system. The graphics are a lot slicker than the version I developed when I was at Visa (after all, it has been about 15 years!), and there is good text, too.
Page 14 offers a description of "convenience fees." The short answer is "the merchant must [Visa's emphasis] adhere to Visa rules." Want to know what the rules are? Simple... "please contact your acquirer."
Also on page 14 is one of my favorite topics: transaction laundering. It says that "Depositing transactions for a business that does not have a valid merchant agreement is called laundering. Laundering is not allowed." That means you don't process for unrelated third parties using your merchant ID. In fact, I wouldn't even allow a third-party merchant on my network. Either it is laundering (I call this "LaunderNet") or you are a Service Provider, and each is bad news from a risk and PCI perspective.
Page 15 tells you not to do cash or check refunds for card transactions. You are supposed to issue a credit back to the original card used. Even if it isn't a Visa requirement, this procedure is a good idea since it prevents another form of transaction laundering: charging a transaction with someone else's card (e.g., their parent's or roommate's, with or without permission) then getting a cash refund. Bad news all around.
Page 17 talks about your third-party service providers.
Check out page 22 for good advice on your POS receipts.
Page 35, and later page 80 cover the CVV2 (the security code on the back of the card).
And of course, if you actually want to learn more than you ever wanted to know about chargebacks and copy requests, that all starts getting serious around page 41.

That Visa released this to the broader merchant community is to be commended. Good job! so do your part and download it now.

Beware of Changes to SAQ C

2011-05-26T13:46:00.000-07:00

Many schools use SAQ C for auxiliaries or other businesses. Sometimes, they will have a point of sale (POS) system that doesn't store cardholder data, but that accesses the Internet for authorizations. If that is you, read on, because a change to PCI v 2.0 may mean you no longer can use SAQ C.

SAQ C previously had five requirements:

the payment system and an Internet connection had to be on the same device
that device was not connected to any other system in the merchant’s environment
the merchant kept only paper reports or receipts
the merchant stored no electronic cardholder data
remote vendor support was managed securely.

The payoff for meeting these requirements was that a school or campus merchant could qualify to use this simplified SAQ and avoid the much longer, more involved, and significantly more costly process of using SAQ D.

Unfortunately some of you will no longer qualify to use SAQ C. The reason is that SAQ C now includes an additional, sixth requirement:

your company store is not connected to other store locations, and any LAN [local area network] is for a single store only.

This change means if your bookstore or food service operation or whatever supports a branch or second (or more) location(s) using their single POS system, they would need to use SAQ D.

The change to SAQ C will affect many universities that have retail or food service operations, and support multiple campus locations with a single POS system. I doubt cashiering operations will be affected very much.

We talked about this issue at the Treasury Institute's recent PCI workshop. I described the changes as part of covering what is new in PCI 2.0. It surprised me how many schools had not noticed the change in the SAQ. I admit it is a subtle change, but it is an important one for a lot of schools. It likely means they either have to license some additional POS applications so they have one for each location, or they are thrown into SAQ D.

If this situation describes your campus, I suggest you get to work on it now and not wait until the last minute. I hate to be the bearer of bad news, but better you should know than get caught up at the last moment

Is Your Website Sending Spam?

2011-04-15T09:27:00.000-07:00

I just saw an updated story on how a number of Higher Ed and government sites have been hijacked by spammers. The sites are used to redirect people to fake online stores.

Are you on the list?

According to the original post at Zscaler there seem to be about a hundred schools that have been compromised including (according to them):

UC Berekely
Harvard
Purdue
Oklahoma State, and
Australian government

The fake stores claim to sell discounted Microsoft and Apple software. Heaven only knows what they are really doing, but the point is that you don't want your institution being part of it.

And the QSA in me has to wonder if parts of the institution's website has been compromised, what about the rest of the site? For example, are you sure your campus merchants who re-direct customers to third-party hosted order pages are really sending them there and not to badguys.com?

Get Ready for Increased Phishing Attacks on Campus

2011-04-07T11:43:00.000-07:00

If the phishing season were not already open, the Epsilon data breach certainly opened it. I recommend two recent articles that you should read and digest.

Over at Threatpost, there is an interview that highlights the vulnerability of higher education institutions. An excerpt is:

Threatpost: What trends are you seeing in the phishing arena these days?
Aaron Higbee: We’re seeing a lot of attacks aimed at verticals like government, financial services, insurance, health care and especially education. You wouldn’t have thought that education would be on that list, but we see a lot of universities targeted.
Threatpost: Why is that?
Aaron Higbee: Students are vulnerable. They’re required to put their Social Security Number into different forms, so they’re susceptible to being phished.

For the best summary of what to expect, surf over to the always informative and insightful blog by Brian Krebs. In this post he assesses the situation and offers some good advice and warnings for your users, particularly staff. This is required reading.

If you ever doubted why PCI requires you segment (read: isolate) your payment environment from other applications and systems in your environment, the Epsilon and RSA data breach should make the wisdom of that requirement clear.

Have a read, then take a look at your own training to make sure you minimize the possible risk to your institution from the expected surge in phishing scams.

RSA Data Breach and Your Two-Factor Authentication

2011-03-17T16:33:00.000-07:00

As we all know, breaches happen. In an open letter to its customers, RSA, the security division of EMC, announced that they had suffered a security breach:

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA's systems. Some of that information is specifically related to RSA's SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

I am not going to speculate on anything, but you should be aware of the situation and monitor developments. After RSA's own statement, a good place to go is the Securosis blog which has its own summary of the situation. Since they did a better job than I could, I'll let you read their analysis of the situation and open questions.

Clearly this is no fun for anybody. But if you use RSA 2-factor authentication -- and who doesn't -- it is worth your monitoring developments.

Your Campus Hotel is Targeted

2011-03-16T08:01:00.000-07:00

If you have a hotel or conference center on your campus, assume it is targeted by criminal hackers who want to get the stash of payment card information they keep.

I've written about this issue before (see here, here, and here). Three major hotel associations issued a joint statement today warning of cybercriminal attacks. Their basic recommendations were:

1. Eliminate EVERY default password on EVERY machine on your network -- server, workstation, router, firewall, and any other device that has a password. The most important machines to check are the ones you think are NOT vulnerable, such as a PC on an engineer's desk for monitoring building systems, or the PC in the parking garage attendant's office, or the one in a closet running your keycard system.

2. Eliminate holes in remote access to systems inside your network.

3. If you don't have a firewall, buy one and install it. If you are connected to the Internet without one, then people you don't know, from around the world and many with malicious intent, are reaching into your network. A recent University of Maryland study counted more than 2,200 attacks on an average Internet-connected computer every day -- equating to one every 39 seconds. If that computer is in your hotel, and if their intent is to steal credit card data, they will probably succeed.

The release also endorses PCI DSS compliance. This is actually pretty smart given their three recommendations are pretty well covered by PCI Requirements: 2.1; 8.3 and 8.5.6; and 1.1 (and all its sub-sections), respectively.

The point is to share this information with your campus hospitality and conference organization. Let them know they are targeted, and to be PCI compliant every day -- not just the one day a year when you do your assessment. If you are not or cannot be PCI compliant today, do your best to protect your network perimeter and at least get rid of a lot of cardholder data that you probably don't need anyway.

Keep in mind the cybercriminals are very smart and well financed. You might also note that as far as I can tell, there are only two kinds of computer systems out there: those that have been breached, and those that are going to be.

Japan Earthquake and Phishing Scams

2011-03-11T08:09:00.001-08:00

In the aftermath of the tragic earthquake in Japan, we can anticipate a swarm of fraudulent websites springing up offering video and opportunities to make contributions to victims. This might be a good time to warn everybody of the phishing risks. The bad guys have no morals, and you can expect your users to receive emails and be searching websites for videos.

The SANS Storm Center contains the following warning and advice:

There will probably be some emails scams and malware circulating regarding the recent Japanese earthquake that occurred overnight.

Be aware off

Fraudulent Organizations: If possible, donate to organizations you know and trust, not to new organizations just set up for this particular event. The IRS maintains a list of tax exempt charitable organizations [1]. This list is not 100% up to date, and it takes a while for a new organization to be added. But it can serve as a first sanity check.

Malware: Malware may be advertised as a video report of the event or come under other pretenses.

You might want to alert your users to be particularly vigilant during this period, both at work and at home.

Vote for NACUBO on PCI Board of Advisors

2011-03-10T13:32:00.000-08:00

If your institution is a Participating Organization on the PCI Council, this post is for you. Specifically, I would like to ask you to vote for NACUBO's nominee to the Board, MaryFrances McCourt. Electing MaryFrances would not only add a very qualified professional (to an already impressive Board), it would give Higher Education a voice at the table where PCI decisions are made.

The PCI Council is holding elections for its Board of Advisors. There are nominees from merchants, financial institutions, and vendors. The top vote getters serve a 2-year term. This is why I am asking if your institution is a member, you make sure to vote for NACUBO's nominee as your top (and maybe only) choice.

Voting is open now and continues until April 8.

MaryFrances is Treasurer of Indiana University. She is active in industry and professional activities outside of IU, and she has been an active proponent of PCI compliance at IU and other forums nationwide. Her hands-on experience in dealing with achieving PCI compliance in an extremely complex environment (a large university) means she can represent Higher Ed's issues and perspective to the PCI Council. Please understand that while MaryFrances works for IU, as a member the PCI Board of Advisors she would represent NACUBO and all Higher Ed, not her institution.

If you are reading this blog and you are not a Higher Ed institution, that means that as a vendor, perhaps, Higher Ed is important to you. May I ask that you please consider voting for MaryFrances and NACUBO as being in both your and your customers' interest?

If your school is a are Participating Organization, make sure you vote for NACUBO's nominee. It is in your own self interest and that of your colleagues at Higher Ed institutions nationwide.

PCI DSS Webinars

2011-02-22T17:03:00.000-08:00

I will be doing a series of four webinars for Heartland Campus Solutions. Here are the dates and times:

March 4, 11 am Eastern
Payment Card Industry Data Security Standard (PCI DSS):
What it is and why it matters to Higher Ed institutions
The first session in a 4 part webinar series helping campuses understand PCI DSS and how it impacts their campus.
March 17, 11 am Eastern
Validating your PCI Compliance:
A Self-Assessment Questionnaire Clinic
The second session in a 4 part webinar series helping campuses understand PCI DSS and how it impacts their campus.
March 24, 11 am Eastern
Third-Party Service Providers and Outsourcing:
A fast track to PCI compliance?
The third session in a 4 part webinar series helping campuses understand PCI DSS and how it impacts their campus.
April 7, 11 am Eastern
Your Campus PCI Survival Guide
The fourth session in a 4 part webinar series helping campuses understand PCI DSS and how it impacts their campus.

You can learn more and register for one or more of the webinars here (you may need to scroll down a little). And before you ask, no you don't need to be a Heartland customer to listen and participate (lots of questions, please!) in any one webinar or the whole series.

For those of you new to PCI (or with colleagues in that situation), these will hopefully be a solid introduction to the standard, especially if they are attending the Treasury Institute's PCI Workshop in May.

I hope to "see" many of you there.

PCI at Educause Security Conference

2011-02-01T14:36:00.000-08:00

I am looking forward to presenting at EDUCAUSE's 2011 Security Professionals Conference. The topic is PCI Compliance in Higher Education, and it will be a practical review of PCI DSS together with some best practices for achieving and maintaining compliance in a Higher Ed environment. Here's more on the conference:

The Security Professionals Conference connects information security professionals, security analysts and engineers, IT staff, privacy officers, C-level executives, and others from across the higher education community. It is the premier forum for strengthening the ability of the higher education sector to protect information assets from the changing threat vectors and respond to the ever-increasing compliance requirements imposed on the higher education community. The Security 2011 conference, "Setting a Course for Collaboration and Innovative Solutions," will focus on security topics that span the information assurance measures of people, process, and technology.

I am doubly excited to be presenting at EDUCAUSE's security conference. First, because they gave me a half-day (3.5 hours...better bring coffee!) at this premier event; and more importantly, because it is a chance to meet with a great group of IT and security people from institutions nationwide.

Here's the plan. The session is Seminar 01-P on Monday, April 4. I'll start out exploring the PCI ecosystem including PCI DSS, PA-DSS, and the card brand mandates. This will be a quick intro for some and review for others. I'll also cover some best practices for meeting what I call PCI Requirement 0 (Reducing scope). That will include outsourcing and related topics. I also plan to delve into changes in PCI version 2.0 and especially the new SAQ C-VT, as well as all the SAQs. I'm looking forward to lots of questions: the last time I did this I got to about my third slide before I was slammed with questions and we went off in whatever direction the audience wanted! I sure hope they have a whiteboard or flip chart.

If EDUCAUSE is in your plans, I hope you will register for my Monday afternoon seminar. Even if you don't like PCI, it's a chance to get to San Antonio a little early and enjoy that beautiful city a bit longer.

Level 2 Schools (And Maybe Everybody Else) - Read This

2011-01-28T14:55:00.000-08:00

The PCI Council now has the full schedule of Independent Security Assessor training on its website (click here to view). Why is this important to all Level 2 Higher Ed institutions? Because under the new MasterCard validation requirements, you either have to have an ISA sign your Self-Assessment Questionnaire (SAQ), or you get to hire a QSA (did I give you my email???) to do it. And as everybody knows, if you are Level 2 for Visa, you are Level 2 for MasterCard even if you have only 1 transaction on that card.

It is great the Council has published the full 2011 schedule. Now you can plan which will be the best one for you. I recommend you surf over and have a look. The ISA training is a bit different this year:

Beginning in 2011 the New ISA training course will have a new look and feel to it to accommodate many of the suggestions the Council has received on the course. The course will consist of two parts: an on-line course followed by a short exam and a two-day instructor-led session ending with an exam.

You should note that only five of the courses are in the US. The other are at other cities worldwide, so depending on your budget you can choose between San Diego or Sydney. There are some basic requirements to qualify for the training, and you can learn all that at the PCI Council's website.

The training is not free: $2,595 for schools that are not Participating Organizations, and $1,595 for those that are. Yet another benefit for those Higher Ed institutions that become POs.

Speaking of price, did I mention that the Treasury Institute's PCI Workshop is a fraction of this price, although you don't get the 2-day in-depth training on every requirement, and you don't get the ISA certification. (Yeah, I know...it's a shameless plug, but what do you expect on the Institute's own blog!?!)

More and more larger institutions are finding that they are Level 2 merchants (over 1 million Visa or M/C transactions per year), and that they have a new PCI validation regime this year. I know this from my own experience with some of these institutions. If this describes your situation, you might want to take a look at this training.

2011 PCI Workshop Agenda now Online

2011-01-27T11:00:00.000-08:00

The agenda for the Treasury Institute's PCI Workshop is now available online at the Institute's website (click here). This is an unique opportunity exclusively for and by Higher Education institutions. NACUBO's support and participation are also valuable in putting on this workshop.

You can register online. I hope to see many of you there! It is a great opportunity to hear great industry and Higher Ed speakers, and a super place to network with your colleagues at other institutions who face the same challenges as you do.

Thanks go to the sponsors: Nelnet Business Solutions; TouchNet; Higher One Payments; CampusGuard; and Fifth Third Bank Processing Solutions. Because of their support the Institute can keep the workshop price the same for the past three years.

Is Your Website Hacked?

2011-01-13T08:43:00.000-08:00

A report today in ThreatPost identifies a number of university websites that have been hacked to redirect visitors to sites hosted by some bad guys.

The Web sites of some of the nation's top universities were discovered to be serving up links to bogus online stores offering everything from popular software by Microsoft to student visas and Viagra, according to a report from security firm zScaler. Portions of Websites belonging to Harvard University, The Massachusetts Institute of Technology (MIT) and Stanford University were found to be redirecting visitors to phony online Web "stores," using multiple languages, that claim to sell software and other goods at discounted prices. The hijacked Web sites have relatively high search engine rankings, which are used to promote the phony Web stores in search results, Zscaler said.

Other sites were similarly compromised including some commercial and government ones. The pattern was the same: redirecting visitors to phony store sites.

How is you school's website doing? It may be worth a look.

"The Best PCI Presentation...Ever"...Sort of

2011-01-04T10:14:00.000-08:00

As I look forward to the upcoming PCI Workshop for Higher Ed institutions (click here to learn more and register!) I am reminded of last year's very strong agenda and great presenters. In particular, I recall Anton Chuvakin's The Spirit of PCI. In case you missed it (or just somehow forgot), he first unveiled his famous "kitten" line...sorry, you'll have to go to Anton's site to see it.

Speaking of the workshop, I am still looking for a presenter or two, especially from a smaller institution. If you think you have a good story to share with your peers, shoot me an email (walt@walterconway.com) and let's discuss.

In the meantime, start making your plans to join us May 9-11 in Indianapolis.

You Have Lost Control of Your Data

2011-01-03T21:34:00.000-08:00

I recommend that if you have anything to do with protecting cardholder data -- or any sensitive personal data -- that you read this post at Securosis. It deals with the reality that business needs will trump security any day of the week. I and others have addressed this topic lots of times in lots of places, but this one post captures the heart of the matter:

First let's point out the elephant in the room: Control. If you feel the need to control your end-user computing environment you are in the wrong profession. The good old days of dictating devices, platforms, and applications are gone -- along with the KGB interrogation lights. You may have missed the obituary, but control of devices was pretty well staked through the heart by the advent of cool iDevices. Yes, I'm talking about iPhones, iPads, Androids, and Palms. OK, Palm not so much, but certainly the others. Some smart IT folks realized, when the CEO called and said she had an iPad and needed to get her email and look at those deal documents, that we were entering a different world.

Lots of folks are calling this consumerization, which is fine. Just like anything else, it needs a name, but to me this is really just a clear indicatiion that we have lost control. But you don't have to accept it. You can try to find a job with one of the five or ten government agencies that can still dictate their computing environment (and good luck as they move all your stuff to the cloud). But the rest of us need to accept that our employees will be bringing their own devices onto the network, and we can't stop them.

Even if you don't read the whole post, just have a look at the Data Loss paragraphs. As my friend Anton Chuvakin is fond of saying, read it for "its sheer awesomeness."

Beware E-Cards!

2011-01-03T08:15:00.001-08:00

I saw two recent reports of malicious email containing innocuous-looking e-cards that reinforce a basic rule that should be part of every organization's security training: Do not ever, EVER click on any attachment (particularly an e-card) unless you are expecting it.

A number of people who should have known better didn't follow this advice. Read on...

In the first case, Krebs on Security reports on a fake Christmas card that appeared from the White House which led to gigabytes of sensitive files being uploaded to a server in Belarus. Merry Christmas, indeed. The card read, in part:

“As you and your families gather to celebrate the holidays, we wanted to take
a moment to send you our greetings. Be sure that we’re profoundly grateful
for your dedication to duty and wish you inspiration and success in
fulfillment of our core mission."

Recipients who clicked the links and opened the file were infected with a ZeuS Trojan variant that steals passwords and documents and uploads them to a server in Belarus. The bad guys managed to collect more than 2 gigabytes of PDFs, Microsoft Word and Excel documents from dozens of victims. According to Krebs on Security, among those who fell for the scam e-mail were:

-An employee at the National Science Foundation’s Office of Cyber Infrastructure.

-An intelligence analyst in Massachusetts State Police gave up dozens of documents that appear to be records of court-ordered cell phone intercepts.

-An unidentified employee at the Financial Action Task Force, an intergovernmental body dedicated to the development and promotion of national and international policies to combat money laundering and terrorist financing.

-An employee at the Millennium Challenge Corporation, a federal agency set up to provide foreign aid for development projects in 15 countries in Africa, Central America and other regions.

There certainly were others. You can read all the details here.

The second case is reported in Threatpost and describes an attack that recently emerged and is (again!) sending millions of emails that appear to be holiday e-cards. The messages all contain short messages similar to this:

Tom has created a New Year ecard.
To view this page please click here: hxxp:maliciousurlgoeshere.com
This message will be stored for 14 days.

Unsuspecting - or untrained - victims who click on the link in the email were sent to one of a number of compromised domains, which then redirect the user to another page that displays a message asking the user to download a fake Flash player. This, of course, installs a piece of malware on the victim's machine.

You can read the full account here.

The bottom line from both these stories is that your sensitive data are only as secure as the least trained user. Remember that when you plan your PCI training for campus merchants and administrators.

In fact, this might be a pretty good lesson for everyone on campus that has email.

PCI "Open Mic" Session

2010-12-22T13:12:00.000-08:00

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?

2010-12-17T10:35:00.000-08:00

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

2010-12-01T14:51:00.000-08:00

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

2010-11-24T09:34:00.000-08:00

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

2010-11-18T15:05:00.001-08:00

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

2010-11-03T18:19:00.000-07:00

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

2010-10-27T16:16:00.000-07:00

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?

2010-10-26T21:05:00.000-07:00

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

2010-10-18T15:46:00.000-07:00

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

2010-10-05T09:31:00.000-07:00

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

2010-09-29T16:42:00.000-07:00

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

2010-09-24T10:50:00.001-07:00

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

2010-09-01T16:00:00.000-07:00

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

2010-08-27T11:31:00.000-07:00

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

2010-08-19T18:11:00.000-07:00

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

2010-08-09T15:57:00.000-07:00

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

2010-08-03T14:01:00.000-07:00

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!?!

2010-07-30T15:15:00.000-07:00

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

2010-07-29T07:49:00.000-07:00

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

2010-07-22T08:54:00.001-07:00

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:

I'm not a Comcast customer. So right there, it was easy to detect.
"comcast" in the second line is not capitalized. A real Comcast email would have capitalized their own companies name.
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.
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

2010-07-14T16:52:00.000-07:00

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

2010-07-10T14:20:00.000-07:00

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

2010-06-15T08:24:00.000-07:00

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

2010-05-21T08:26:00.000-07:00

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

2010-05-20T07:46:00.000-07:00

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

2010-05-19T10:32:00.000-07:00

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

2010-05-13T17:01:00.000-07:00

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

2010-05-07T13:51:00.000-07:00

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

2010-04-26T10:53:00.000-07:00

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

2010-04-20T21:50:00.000-07:00

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

2010-04-19T11:08:00.000-07:00

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

2010-04-04T15:02:00.000-07:00

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

2010-04-01T07:11:00.000-07:00

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

2010-03-30T16:00:00.000-07:00

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?

2010-03-29T20:25:00.000-07:00

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

2010-03-18T08:38:00.000-07:00

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

2010-03-12T08:07:00.000-08:00

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

2010-03-09T07:23:00.000-08:00

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:

If you have customers or employees, you need to safeguard personal information.
Laws do not usually establish Privacy Practices. Privacy Policies create Privacy Practices.
Privacy Policies are often required by law or regulation.
Your business faces privacy challenges which nobody else faces.
Cloud Computing, Social Media, Goods and Services, Employer, and other activities pose unique challenges to handling personal information.
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.
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?

2010-02-24T11:41:00.000-08:00

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

2010-02-18T17:09:00.000-08:00

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

2010-02-16T11:46:00.000-08:00

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

2010-02-15T15:09:00.000-08:00

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

2010-02-01T08:38:00.000-08:00

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.

Changes for PCI In October: "No Surprises"

2010-01-28T08:42:00.001-08:00

I just saw a report that reference recent statements by Bob Russo, General Manager of the PCI Council, where he talked about possible changes to PCI in October.

According to an article at SearchSecurity, Russo said "There won't be any surprises. We're more likely to see guidance documents." In a lot of ways, this makes sense. The Council is studying a number of relatively new technologies (a couple of examples are end-to-end encryption and tokenization, but there are others) and their impact on both merchant compliance and the DSS itself. With some guidance from the Council, merchants will be more comfortable making choices and deciding how to implement them. As Russo explained:

"End-to-end encryption is a catchphrase because at a certain point along the line, the data needs to be decrypted," prompting key management questions, Russo said. "Key management introduces a whole new series of issues that could cause you to be less secure."
Russo said he doesn't expect an end-to-end encryption special interest group will study the issue. Instead encryption within the payment process will be addressed when other technologies that affect the payment process are identified and studied. The Virtualization Special Interest Group, due to recommend guidance in March on protecting card data within virtualized environments, will address the role of encryption as well, Russo said.
"Unfortunately there are so many different technologies that merchants may have started down the path with that we need to be careful and study them before prescribing them in the standard," Russo said.

We are just over 3 months away from May when the Council will publish the revisions to the DSS for Participating Organizations. I am hoping we have specifics for the Treasury Institute's PCI Workshop (hint, hint...), but at least we'll have Bob Russo himself there - live and in person - speaking to us.

Cost of Data Breach Study Updated

2010-01-25T17:01:00.000-08:00

Ponemon Institute together with PGP Corporation just released their 2009 U.S. Cost of a Data Breach Study. The bottom line is that the cost of a data breach increased to $204 per record compromised, a small increase from the $202 figure for 2008. Perhaps more important than the average, per-record statistic is the total cost of a data breach. Despite an overall drop in the number of reported breaches, the average total per-incident costs in 2009 were $6.75 million, compared to an average per-incident cost of $6.65 million in 2008.

Some of the highlights of the study are:

The cost of a data breach as the result of malicious attacks and botnets were more costly and severe.
Negligent insider breaches have decreased in number and cost most likely resulting from training and awareness programs having a positive affect on employees’ sensitivity and awareness about the protection of personal information. Additionally, 58 percent have expanded their use of encryption up from 44 percent last year.
Organizations are spending more on legal defense costs which can be attributed to increasing fears of successful class actions resulting from customer, consumer or employee data loss.
Average abnormal churn rates across all incidents in the study were slightly higher than last year. The industries with the highest churn rate were pharmaceuticals, communications and healthcare, followed by financial services and services.
Third-party organizations accounted for 42 percent of all breach cases, dropping from 44 percent of all cases in 2008. These remain the most costly form of data breaches due to additional investigation and consulting fees.
The most expensive data breach event included in this year’s study cost a company nearly $31 million to resolve. The least expensive total cost of data breach for a company included in the study was $750,000.

You can download the entire report (registration required) here.

Will Cyber Attacks Hit Higher Ed Next?

2010-01-22T09:02:00.000-08:00

With the recent attacks on a number of high tech companies like Google and Adobe, can we expect similar cyber attacks soon against higher education institutions?

I have to believe leading research institutions are or have been targeted for their research and intellectual property assets. I am speaking on this topic next week at the Treasury Institute's Symposium. My talk ("A Senior Management Perspective on Cyber Security") was originally aimed at the usual trojans and malware, but the news these past weeks have me updating my message.

What has me particularly concerned is an article in CSO Online entitled Botnets: The Democratization of Espionage by Brian Krebs. Read it. While the attacks on Google et al were not by botnet, the scope of botnets can give hackers - even the ones that are just plain old criminals and not nation states - the tools to compromise your systems and data.

Your networks are being scanned continuously by the bad guys looking for a way in. The threat is not going away. It can only get worse.

PCI Security Policies and You - Part 3

2010-01-15T14:43:00.000-08:00

When the going gets tough, the tough get help.

At least that's how I look at it, especially when dealing with policy development.

An automated PCI security policy template is a productivity tool that makes sense. A tool - any tool - can't write a good policy for you. What it can do, however, is give you a starting point and guide you along the way to developing all the policies you need. A good tool provides a discipline and thoroughness to keep you from missing something important. It also saves you and your colleagues time and effort by letting you focus on what is important: developing actual policy details that work for your school.

A good security policy template provides you with a structure while preserving flexibility. It also should lead you to additional resources where this can be useful. I've provided an example of this above for a policy addressing web application security policy. (Yes, I know it's impossible to read, but if you click on it you should get an enlarged version.)

Another feature to look for in a policy template is the ability to cross-reference your policies to the PCI requirements. I'm not saying that your policies have to mimic the DSS numbering system, but being able to cross-reference your policies to the DSS can be a time saver.

So the obvious question is where can you find a security policy template? The obvious first answer may be to search the web, but my personal opinion is that this would be one case where Google is not your friend: I searched for "security policy template" and turned up over 41 million links.

A better approach would be to start with the public sources noted in the previous post. Some of these sources may have templates although I'm not sure all are PCI-specific. You also can ask your QSA if they have a policy template tool. Many QSA firms have templates that you can buy and use on your own or with additional consulting assistance. Either way you get a tool that is designed to help you write high quality PCI security policies in the fastest and (hopefully) most painless way. There will be a cost for the templates and for additional support, but compared to the person-hours you will save over developing your own policies from scratch the investment may make sense.

Another approach is to take advantage of the fact that Higher Ed institutions collaborate. Check with your peers who are managing the PCI program for their schools to see if they have policies that you might be able to use as a guide. They may not be able to solve all your needs, but maybe they can give you a start.

I am planning on a session at the Treasury Institute's PCI Workshop in May addressing PCI policy development. Several individuals have volunteered to help, so I am hopeful we will have a good discussion. (You have registered for the Workshop, right...?)

In the meantime, give a thought to using a policy template. Your PCI policies do not have to be long, wordy documents. My own belief is that policies should be simple declarative sentences. The fewer words the better. Your procedures may be more lengthy, but the policies can be straightforward, so don't fall into the trap of making them cover every possible contingency.

That's another advantage of a template: it keeps you focused.

PCI Security Policies and You - Part 2

2010-01-12T20:57:00.000-08:00

Above is a table. It's kind of hard to read, but if you click on it you should be able to get a larger view of it. Security poicy requirements affect to some degree every campus merchant the table maps the PCI requirement needing a written policy to the respective Self Assessment Questionnaire (SAQ).

For example, a merchant that outsources its processing and qualifies to SAQ A has to implement policies for managing their service provider(s) (12.8) and for handling the paper media with cardholder data (9.7, 9.9, and 9.10). I decided to include 3.1 in the table since to meet the relevant parts of requirement 9 you need to develop a data retention and disposal policy.

If you use another SAQ you have more policy work to do.

Your first option is to develop your security policies independently from scratch. This choice has the advantage of responding to your organization’s operations and business needs and culture.

Your second option is to search for models templates to give yourself a head start. This is the “Google is your friend” approach. If you decide to follow this approach, three sites in particular merit your attention:

SANS Institute has a excellent resources including whitepapers that can help get you started
NIST’s Computer Security Resource Center is another good source

Educause has a Data Incident Notification Toolkit.

One problem with any of these resources is that the examples may not match your school's exact needs. Another problem is that none is designed to be PCI-specific, and none really covers all the requirements. That is, you will still have a lot of work to do modifying whatever you download to fit your PCI needs.

The good news is that many schools view their security policies as public information. As a Higher Ed institution, you are part of a very collaborative group of people. Therefore, some of the best potential examples may be available to you on the web.

But if you can't find good examples, there may still be an option.

That will be the subject of Part 3.