Skimming Cards at the POS

When I am named emperor of PCI, I will require every card merchant (including on every campus) to physically inspect each POS device regularly for evidence of tampering.  The PCI Council provides guidance and examples in its Skimming Prevention: Best Practices for Merchants information supplement (in the Information Supplements section).  Personally, I think it is possible that such physical inspections could be included in the revisions to PCI 3.0 and the SAQs in 2013.

In the meantime, there is no need to wait until it is required.  You can start doing it now.

I am reminded of this whole topic by the post in Brian Krebs' blog describing fake/compromised POS devices used by criminals to steal card data.  At least one criminal is selling compromised POS devices -- including top-of-the-line cellular-based wireless devices -- that capture the mag stripe, and print a receipt, but never actually complete the transaction.

This scam is not new.  I remember stories during my time at Visa about merchants who "sold" goods for the sole purpose of collecting payment card data.  Customers were surprised they never saw the charge for the t-shirt or other tchotchke on their account statements.  The reason was that the "merchant" never had any intention of charging their card -- they were just skimming the stripe.  Giving away the merchandise was a minor cost of doing business.

The difference today is that the scam is getting more sophisticated.

So some advice for everyone is:

• Check your own POS devices for evidence of tampering regularly (monthly?  weekly?).  What is a good practice today may be required by PCI tomorrow.    
• Contact your issuer if you buy merchandise and no charge appears on your statement (no, you didn't get a special deal...you possibly were scammed).  And if you used a debit card (eek!), get very, very worried.  
• Never, NEVER get POS devices from anybody but your acquirer.

Oh, and I almost forgot.

• Continue to monitor security websites other sources of information (like the list of blogs on the right) to stay current.  

Before You Leave for the Holidays...

There is an excellent post at the SANS Internet Storm Center on what IT departments and users (!) should do to remain secure over the upcoming holiday break.  That advice is reproduced in its entirety below:

With the holidays coming up, you might think it's time to stop thinking about security, malware and generally anything to do with work.  Unfortunately, in the area of security, the holidays are not the time to let your guard down.  It's always fun to see the up-tick in malware over significant holidays, because the malware authors plan for the time windows when their targets (that's you and yours) and the AV vendors are at reduced staff levels

So, what should Corporate IT folks be thinking about?

Before your users go home for the holidays, ensure that everyone has their Antivirus set up to auto-update over the web.  In some corporate setups, AV clients update from a corporate server.  If your user community is all offsite over the holidays, they won't get their updates when they need them the most.  Which means that some of your users will come back in January infected, and (likely) with their AV turned off by the malware they've picked up.

Similarly on the OS Side - if your users are using WSUS or some other central update service, you likely want them to either update over the internet, or force them to VPN in to get updates.  There's nothing like a zero day loose on your corporate network to make for an exciting January!

If you are on the security team, keep track of your system logs.  In particular, keep track of backup logs and IPS logs.  Even little stuff missed over the holidays does nothing but get worse over the two weeks we have off!

Think about spam.  We're all expecting a flood of e-cards in our mailboxes from friends, family, customers, vendors, and other people we do business with.  Mixed in with these expect to find some malware, and maybe even some new, ingenious malware.  It's a good idea to send a note to your users to let them know to look out for spam that might get past the filters.  Remind them that if a website or an email attachment tells them that "they might be infected", they should close that window or maybe even instruct them to reboot to kill it (you'd be surprised how many folks will press "OK" to close a window).

Think about new devices.  Off-brand picture frames have come with malware in the past, but you could just as easily see malware on cameras or those keychain picture frames.  Really, anything with a USB port that might be infected, even stuff you might not think about like USB powered remote control helicopters and cars - - yes, some of your users will plug these into their corporate laptops to charge, even if there's a charger in the box.

Your users will absolutely come to back to work with new tablets, mp3 players and phones - all of which "must" have a network connection.  If you don't already have a plan (and a written policy) for dealing with these, you may have an uphill battle ahead of you (or maybe it's a battle you might have already lost)

Whatever it is, if you're in IT, expect an evil present or two from your users in January.

What should you be thinking about if you're at home, and you're NOT in IT?

Well, all the same stuff.  Be sure that all the computers at your house are updated, and have up-to-date AV protection.  Think about e-cards and other holiday spam and malware when you open mail.  Think about USB and network attached devices after it gets unwrapped and eveyone wants to start plugging cables in.

And think about your extended family who might be calling you after "everything got really slow on our computer after Christmas, right after we uploaded our pictures to that new picture frame".

Because we all know that even if we're not in the IT department at work, we're certainly an "IT department of one" after we get home !

Have a good, safe holiday everyone !

Confidential Information Found in Macy's Parade Confetti?

There is a reason why PCI DSS Requirement 9.10 requires that merchants and service providers use a crosscut shredder to destroy paper records with confidential information.  The reason is that simple ribbon-type shredders don't really destroy the information.  Depending on how the paper goes into a ribbon shredder, whole lines of information can be readable.

If press reports are accurate, the organizers of the Macy's Thanksgiving Day Parade together with the Nassau County Police are living proof that ribbon shredders are not very valuable.  Based on news reports, the police are investigating claims by attendees at the Thanksgiving Day Parade that the confetti  that poured from the sky contained Social Security Numbers, bank account numbers, and police records that were clearly readable.

One important lesson for any organization with confidential financial, medical, or personal information is that shredding means crosscut shredding.

A second, possibly equally important lesson is that if you use a shredding service for your PCI documents (or HIPAA or whatever), you better know what they do with the chad after they shred the documents.  Do they sell it for pulp?  Do they recycle it?  Do they sell it to parade organizers or party planners for confetti?

The reason this second lesson is important is that the shredding service is a PCI Service Provider, and 12.8.2 says you need to have an agreement that they acknowledge their responsibility for the cardholder data (the paper) they possess.  That means you might want to know what happens to your confidential documents once they leave your premises.

Maybe we need to add this "Macy's Rule" to PCI?

2013 PCI DSS Workshop - Call for Topics and Presenters

The Treasury Institute's tenth (!) PCI DSS workshop will be May 13-15 in Indianapolis.  Click here to go to the website to register and for hotel information.

This is also the start of my call for speakers and topics.  What do you want to see covered this year?  Is mobile still hot?  What about cloud and ecommerce implementations?  How good are your policies?  What do you do for remote events (e.g., athletics, golf tournaments, etc?).  Are you ready for EMV chip cards?  What is the latest from the card brands (e.g., see here)?

This year, in response to your comments from past workshops, we expect to have separate IT and Business tracks for one half-day (probably Tuesday afternoon).  That means the Institute (and I, as organizer) want to hear from presenters about IT-specific (be as geeky as you want) and Business -specific (be as practical as you want) subjects.  If we get some good ideas and speakers, we'll go with the separate tracks on Tuesday pm.

Speakers get special treatment to thank them for their time.  The Institute will pay for speakers' hotel, and they attend the workshop for free.  If you propose a joint presentation, only one speaker will get the hotel and comped conference fee.  About all you have to do is get yourself to Indy (especially since two breakfasts and lunches are included).   Speakers also get the opportunity to sharpen their presentation skills in an open and supportive atmosphere with a group of their peers.

Please contact me directly (wconway@403labs.com) to propose a presentation.  I look forward to being flooded with suggestions.

It is now up to you!  Please feel free to re-post this announcement to appropriate listserves and bulletin boards.

Visa Extends Service Fee Program to Higher Education

Effective November 6, Visa has expanded their program allowing government agencies to add a service fee Visa card payments to include Higher Education.  This is potentially big news for every school that accepts or wants to accept payment cards for payment of tuition and fees.  Visa's statement reads in part:

To regain acceptance and increase competitiveness in the Government and Higher Education segments, effective 6 November 2012, Visa is expanding the Tax Payment Program and renaming it the Government and Higher Education Payment Program. The expanded program will include government merchants (Merchant Category Code [MCC] 9311—Tax; MCC 9222—Fines; MCC 9211—Court Costs; and MCC 9399—Miscellaneous Government Services) and tuition and related payments for higher education (MCC 8220—College Tuition; MCC 8244—Business; and MCC 8249—Trade Schools). 

Visa currently does not permit variable fees on any type of U.S. payment transaction, other than on tax payment transactions. By expanding the Tax Payment Program, Visa seeks to regain lost Visa acceptance among higher education and government merchants.

Here are some of the details:

• This is not a new program.  Rather, it expands the current program allowing surcharges for government agencies to additional merchant category codes that include Higher Education.
• The program includes card-present as well as card-not-present transactions
• The program includes credit and debit cards

If your school wants to participate, you have to do a couple of things:

• First, your institution has to register with your acquirer.  You should contact your acquirer to get the Government and Higher Education Payment Program Guide, which has the form you need to file to register for the program. This guide also has all the program details.  Note there is no fee for the registration, but your institution has to do it.  
• While you are talking with your acquirer, make sure they have assigned you the right Merchant Category Code (MCC).  This program only applies to transactions in MCCs 8220 (College Tuition), 8244 (Business schools), and 8249 (Trade schools).  This is important, and you may need to hold your account rep's hand through this process.  In my experience, schools may be classified into MCC 8299 (Miscellaneous education).  If that is you, then you need to get your MCC changed or you will not benefit from the program.

The payment and service fee transactions must be submitted and processed as two separate transactions as noted below:

• The transaction must include: 
• The higher education institution (merchant) name in the Merchant Name field (merchant name cannot exceed 25 characters in length) 
• Customer support phone number in the Merchant City field 
• State of the merchant in the Merchant State field 
• The service fee transaction must include: 
• Merchant or service provider name in the first 3,7, or 12 positions followed by an asterisk (*) in the next position, followed by the words “Service Fee 
• Customer support phone number in the Merchant City field 
• State of the service provider in the Merchant State field.

There are some other conditions described in the Program Guide, but they are not out of the ordinary.

All of this means that those institutions that had not accepted Visa in the past because of the service fee prohibition are free to add that card brand.  All you need to do is register with your acquirer.  

This is potentially big news for many institutions.  Spread the word.  Please feel free to post links to this post to listserves and bulletin boards as you wish.  

Thousands of Records Reported Taken from 53 Schools

This is scary.  Hackers breached 53 schools this past week.  While it is unclear if any confidential data were compromised, thousands of records were stolen and dumped.  This event highlights the importance of security throughout the campus, and it also highlights why PCI DSS Requirement 12 talks about security (not just PCI) training.

Some Good Advice for Merchants

Visa released some interesting documents this week.  You might want to have a look at one or all of them:

• Here is a link to merchant training Visa offers.  The current session is for franchises, but there may be some good information there for others, too.  Visa usually posts the slides from these sessions online, so you can always check back later to see what you missed.
• The Security Tips for Retailers is valuable for understanding what is cardholder data and how to avoid storing sensitive authentication data like the security codes.  It reinforces the maxim: if you don't need it, don't keep it.  Good advice.
• Perhaps the most valuable is Visa's ecommerce tips and best practices for small merchants.  The PCI Council's ecommerce Special Interest Group (SIG) has completed its work, and that report should be available later this fall.  In the meantime, have a look at this document.  

Lastly, there is a good article featuring Branden Williams (there is a link to his blog on the right) that is worth reading.  He addresses particular practices for card-present or brick-and-mortar merchants.  You can read it here.

PCI Council on Mobile, EMV, ecommerce, and Listening

There is a very good interview at BankinfoSecurity where Bob Russo (PCI Council General Manager) and Mike Mitchell (PCI Council Chairman) address initiatives and objectives for the Council and the standards in the coming year.

Many of you have heard Bob Russo speak at PCI Workshops or other public forums.  I got to meet Mike Mitchell earlier this year when we sat down to talk at RSA.  With the PCI Community Meeting coming up next week, the interview tells me several things.  First, mobile payment solutions rank high on the Council's agenda.  This is no surprise, and with the speed of merchant adoption across the merchant spectrum (including many of your campuses, whether you wanted it or not!) it is welcome news.  They also cite Point-to-Point Encryption (P2PE), which is my personal favorite technology that can reshape completely the merchant compliance framework.

Next week is what I call the "feedback" meeting.  The Special Interest Groups (SIGs) will report on their recommendations.  I will pay a lot of attention to the Cloud SIG in particular.  The ecommerce SIG will report its findings, too (and yes, that'll be me up there for my 15 minutes of PCI fame).  I feel our final report, which should be ready this fall, will be valuable for higher ed institutions.

For it to be successful, the feedback meeting has to also be the listening meeting.  Everyone should be encouraged by the detail the PCI Council provided on each individual piece of feedback they received.  Really: the report was 66 pages long!  Participating Organizations got to see every comment, and they got to see the Council's decision: e.g., whether it was accepted for current consideration, not accepted, or postponed for later consideration.  Every person may not have agreed with every decision, but at least everyone who commented knows they were heard.  It doesn't get much better than that.

Speaking of listening, I'm looking forward to the Associations breakout session.  That is where associations like NACUBO that represent industry segments get together with PCI Council staff and the card brands.  The rules of the game are that much of the content of the Council meetings and deliberations (including the Association meeting) are confidential...what goes on in Orlando stays in Orlando, I guess.  Therefore a lot of the discussions are not fair game for posting in blogs like this.  To the extent there are things to report, I'll be writing more from Orlando.

Meanwhile, surf over to the interview with Bob and Mike.

Feedback on PCI DSS and PA-DSS v2

The PCI Council issued a press release summarizing the feedback on the current versions of PCI DSS and PA-DSS.   Recall that PCI follows a three-year lifecycle, and we are in the middle of the feedback period, Period 6.  The Council will cover the feedback at next week's Community Meeting, which I will attend.

Here are some of the highlights based on my perspective:

• The vast majority of feedback pertained to PCI DSS vs. PA-DSS.  Feedback came from a range of Participating Organizations (POs), QSAs and ASVs.  Quite a lot of the feedback seemed to come, not surprisingly, from assessors.
• Based on the press release some of the main areas for comment are
• Revising the Self-Assessment Questionnaires (SAQs).  Some commented they are too complicated (I assume they mean the qualifying criteria), but others pointed out additional requirements that may be needed.
• Clarifying who is a Service Provider under PCI DSS Requirement 12.8.  Huh!?!  What is it about "you can affect the security of the transaction" that you don't understand?  
• Scoping.  Let's all agree this is one of my hobby horses.  I most recently wrote about it here and here.  Hopefully there will a good discussion of this topic next week.  Based on the feedback, more guidance is still needed.
• Cleaning up the password requirements in PCI DSS Requirement 8.5.  I really agree with this one meriting a fresh look since the level of detail seems too much for many organizations.  We'll see what happens.
• Determining what constitutes a "significant change" that triggers the need for a re-scan or even a new penetration test (PCI DSS Requirement 11.2).  Anytime we use imprecise terms like "significant," it is a double-edged sword: it offers flexibility, but it can be abused.  

For another take, have a look at Branden Williams' blog post on this same topic.

I noted that this feedback is Phase 6.  The next two phases involve drafting proposed revisions to the two standards (Phase 7), and then the final review (Phase 8).

Thanks to all who forwarded your feedback to Tom Davis and me.  We'll report back to you after -- and likely during -- next weeks Community Meeting...aka, PCI Woodstock...

Preparing for Your First Security Breach

I recommend you take a few minutes to read this post about preparing for your first security breach by Conrad Constantine at Alien Vault.  He offers some good, personal advice that probably is not in your Incident Response Plan (you do have an IR plan, right???).

Some of my favorite recommendations he makes are:

Before anything else, no matter what field you work in during times of crisis you will see everyone's true colors brought forth - not least of which - your own. You will know more about yourself and your co-workers after the event than you ever did before.

[Senior executives] are going to require fast and decisive answers from you - welcome to their world - you will be asked to make quick assessments of the information you have available and be held accountable for them afterwards. 

Your first responsibility will be to create a complete and detailed timeline. [Note: I completely agree with this recommendation!]

Things are going to get a little crazy, requests become orders and niceties fall to the wayside.

 And maybe my favorite line:

In this day and age, it is an accepted truth that all organizations will be breached at some point - what is important is how you handle it.  

I am not a data breach expert, but I have been involved in a couple of breach or suspected breach situations.  The thing to remember are that nobody is going to be able to think clearly, so have a good plan.  Then develop your detailed timeline, document it, and maintain your sanity as best as you can.  Even if you are only on the periphery, events and people can get strange.

Read the article and maybe put a copy with your IR plan -- you are likely to need both at the same time.

  

  

PCI DSS Scoping Toolkit is Released

One of the most difficult and important tasks in any PCI DSS compliance assessment or gap analysis is determining your PCI scope.  That is, identifying which processes, networks, and systems are in scope for PCI compliance.  If you underestimate your scope and miss things, you put your institution at risk for a damaging and expensive data breach.  If you overestimate your scope, you may consume unnecessary amounts of money and resources.

Recognizing the importance of properly determining PCI scope, the PCI Council established a Scoping SIG in 2009.  Full disclosure: I was a member of that SIG although I played only a minor part.  While that SIG never issued its final report, the participants did a lot of good work.  Some of the SIG's insights I've shared with clients on occasion, but the report was never released.

Some of the members of the SIG have now released what they are calling the Open PCI Scoping Toolkit.  The Open Scoping Framework Group states:

The Toolkit includes a set of principles, a structured thinking process and tools to generate defensible and consistent scoping conclusions, regardless of who is performing the PCI evaluation or assessment. In the absence of such a tool, or unambiguous guidance released by the PCI Security Standards Council, questionable scoping decisions will continue to be made.

In the future, we will be expand upon the Toolkit, and present its application to some of the toughest PCI scoping scenarios, along with our suggested scoping conclusions. These include hotel front desk networks that include POS systems and guest PCs, order entry systems running on thin clients in retail stores, virtualized servers processing cardholder data, and ActiveDirectory systems providing authentication to systems processing cardholder data.

We expect that practitioners will use the Toolkit to make scoping decisions, with a level of consistency and precision that has eluded the community to date. We believe the Toolkit to be consistent with the spirit and intent of the PCI DSS.

You can also check out my StorefrontBacktalk column this week for a personal take on the toolkit.  I'll let you surf over there (no registration required) rather than repeat myself here.

Please know this Scoping Toolkit is not endorsed by the PCI Council.  However, whether you agree or disagree with the approach, I suggest you consider it as you assess your institution's own PCI scope.

Part 2: The Credit Card Settlement and You

A few weeks ago I wrote about the pending settlement between Visa and MasterCard in a major lawsuit.  A key element in that settlement is the ability of merchants to add a fee for credit cards.  

According to an article in today's New York Times, it looks like the settlement has been accepted.  I suggest you use the link above and read the article.  

Some of the issues you may want to think about:

• Does surcharging make sense?
• Will this allow those campuses that accept MasterCard only not to accept Visa, too?
• What about debit cards, and the differing rules between Visa and Mastercard?

While this is not necessarily a PCI issue, the settlement does affect your payment card program.  

Ten Ways to Fail at PCI

A column by Ericka Chickowski at Dark Reading describes ten ways to fail a PCI DSS compliance assessment.  Here is a brief summary of each of the ten missteps together with a little personal commentary:

1. Pick the first QSA who comes along.  Good advice.
2. Skip a pre-audit assessment.  For anyone but a Level 1 merchant, this means failing to conduct a PCI gap analysis.  The gap analysis should point out not only your current compliance gaps and remediation options, but it should also identify areas where you can reduce your PCI scope by making business process or technical changes.  It goes back to item #1 - picking a QSA that knows more than just the details of PCI can be a good idea.
3. Skip a pre-audit checklist.  OK, I'll admit it.  I hate the word "checklist" in the PCI context, but here it makes sense.  This means understand what documents you need as evidence of your compliance.  For example, written security policies and having the right people lined up for your PCI gap analysis.
4. Poor documentation.  If it is not written down, it doesn't exist.  
5. Bad assumptions.  If you only read the words in a PCI requirement, you can miss the intent.  Focus on the intent and you can save a lot of wasted effort and heartache.  This is where a QSA who lives in the PCI "echo chamber" can help supplement your internal resources.  
6. Too much data.  Too often PCI teams fail to ask the question: "Why do you need that data?"  If you get an answer that rhymes with "Well, we always did it that way" you could be on the track to having too much cardholder data to protect.  And too much data translates into added cost and, importantly, added risk.
7. Ineffective scoping.  Scoping is critical, and it can be difficult in the absence of good, detailed network diagrams.  Well-constructed dataflow diagrams can help identify systems and devices that are in scope for PCI.  Finding another network segment or system half-way through the compliance effort is no fun for anybody.
8. Blindly trusting your software application.  This one may be my second-favorite.  The dangerous refrain is: "We have a PA-DSS validated app, so we're compliant."  Perhaps the only more dangerous thing would be to believe that statement.  Payment apps have to be installed and maintained, and just because they are PA-DSS validated does NOT mean they don't store electronic cardholder data.  Validated apps help compliance, but they are not a silver bullet.
9. Blindly trusting your service provider.  This one is my top choice.  I'm going to hold off my "you can outsource your processing, but not your responsibility" speech (er, rant?).  I will simply say that any merchant who does not use Level 1 service providers exclusively (listed on Visa and MasterCard websites) is making a mistake and taking undue risk.  The same goes for using a reseller/system integrator for your application (see #8) who has not been through the PCI Council's training program.
10. Thinking your SAQ means you're done.  PCI is a program, not a project.  Celebrate your accomplishment in validating your compliance, but remember there is always something you need to be doing.  PCI is the gift that keeps on giving.

 There you have it.  Read Ericks's column and apply it to your own situation. 

PCI Training Options

There are few areas where training pays bigger dividends than complicated, high risk areas like PCI compliance.  The reasons are that the standard is complex, detailed, and if you mess up your institution's reputation (and checkbook) may be at risk.

One of the best sources of information sharing and training is the Treasury Institute's annual PCI Workshop.  (Click here for a link to the 2013 Workshop).  There institutions of all sizes from across the country (and Canada) come to share experiences, lessons learned, and best practices in achieving PCI compliance on their campus.

The PCI Council also offers an increasingly broad array of PCI training sessions for merchants.  If you want the same training as QSAs receive, you can pursue the Internal Security Assessor (ISA) program. There also is PCI Awareness Training for executives and managers -- no previous PCI experience required.  A big difference -- and maybe an advantage -- is that attendees in the PCI Council sessions come from all industries, not just Higher Ed.  Therefore, these may provide a broader perspective on issues and solutions.

The programs of the Treasury Institute and the PCI Council are complementary, and between them they offer schools a range of options.  The only way you can lose is by not doing anything.

Special Interest Groups for 2013

Do you have questions about PCI?  Is there a technology you want to know more about?  Is there some part of PCI that drives you or your colleagues nuts (er, that's a technical term...)?  If so, then the topic might be a good one for a Special Interest Group (SIG).

The Council is looking for suggestions for the 2013 SIGs.  As a Participating Organization, NACUBO has the opportunity to nominate topics.  But to do that, NACUBO needs to hear from you.  Please reply to this post or send an email to me (wconway@403labs.com) or Tom Davis (tdavis@iu.edu) with your suggestion.  The deadline if July 31.

The Credit Card Settlement and You

By now, you should be aware of the proposed settlement involving both Visa and MaterCard (see here, and here for the NYTimes update ).

Based on the summary at Payments News, there are some things to note and be aware of.  First, here are the three elements of the settlement:

• Reduced credit card interchange for a period of eight months.  This should result in a drop in merchant fees for the "affected class."
• A change in card brand rules to allow merchants to surcharge under certain conditions.
• An agreement whereby the brands will meet with groups of merchants to negotiate interchange rates collectively.

Each of these has potentially significant impact for Higher Ed institutions and their card programs.

The reduced fees should show up in lower merchant fees.  That is, the plan is for acquirers to pass along those savings to merchants.  If the settlement goes through, and if the interchange rate reduction includes all merchants (which is unclear), you want to check that you receive the savings.  The savings may not be large, but every little bit counts.

The surcharging rules may open the doors to re-consideration of card acceptance at many institutions.  It is no panacea, and adding a percentage (assuming that will be allowed) is not very customer-friendy.  Nevertheless, surcharges may allow more schools to take cards (or at least to also accept Visa) than in the past.

Lastly, there may be room to negotiate a "Higher Ed" interchange rate with the card brands.  This is a long shot, but I know from personal experience that a lot of schools and their associations have expressed interest in talking to the card brands about a lower interchange fee for Higher Ed based on the lower risk of the transactions.  We'll have to see what happens here, but this may be the greatest impact on Higher Ed.

Stay tuned.  If this settlement goes through, it could be a significant change for Higher Ed and payment cards.

Still Think You're Not Vulnerable?

The bad guys increasingly target small businesses.

We know that as a fact from published statistics, and now from a recent incident reported Aviva Litan in her Gartner blog.  In this case, a small restaurant in an equally small town had their POS system hacked.  The bad guys got away with a load of card data, with the result that a disproportionate share of local residents (including any number of the local police force, many of whom at at the restaurant) have their cards compromised.

The stolen cards have been used all over the world, so it's unlikely the bad guys will be caught.  The cardholders will be inconvenienced, but likely made whole by their card issuers.  The issuers will face the losses, but it is the hapless restaurant that will likely suffer the most at the hands of the card brands and their acquirer.

If a data breach can happen at a small merchant in a rural town, I hope everyone reading this realizes the same can happen to a university merchant just as easily.  The bad guys are scanning your systems every day, but one big difference between them and your ASV is that your ASV gives you a report of your vulnerabilities.

Combine the vulnerabilities of small merchants with the visibility and vulnerabilities of higher ed institutions, and we can see that PCI compliance truly is not an option.  

Change in Credit Card Surcharging Coming?

In case you missed it, there is an article in the June 9th edition of the Wall Street Journal (you may need to be a subscriber to see it all) that can affect your entire payment card program.  The Journal reports that both Visa and MasterCard may soon allow merchants to add surcharges to payment card transactions.  Currently, both organizations ban such surcharges.  As the they report:

But Visa and MasterCard, which operate the world's largest card-payments networks, ban the practice in the U.S. as part of rules they require retailers to follow to accept their cards. That ban is expected to be eliminated or altered, though, under a potential settlement of long-standing lawsuits retailers have brought against the card networks and numerous banks that issue their cards.

Two points you should note, however:

In the U.S., 10 states, including New York and California, have laws prohibiting surcharges, according to Visa. It is unclear whether merchants in those states would be able to engage in the practice if Visa and MasterCard allow it.

and

A change in Visa's and MasterCard's rules also wouldn't affect purchases made with cards from American Express Co and Discover Financial Services ... aren't part of the litigation.

Naturally, nobody involved is commenting, but if the ability to surcharge plastic payments is part of the settlement, it could take place as early as this fall.  Another part of the reported settlement would be reduced interchange fees, which translates into lower costs for merchants.

Speaking of this fall and lower costs...

Could this settlement -- if it happens -- lead to increased card acceptance for tuition and fee payments?

Eek! Is My Email System in PCI Scope!

I once saw a t-shirt that read: You Can't Patch Stupid.

It is tough to argue with the wisdom of that statement or its directness, particularly when it comes to receiving unsolicited emails containing cardholder data.  The real issue, though, is what is a merchant to do when they receive such unsolicited orders or gifts?  Did the sender just put the institution's email system in scope?  Can they process the transaction "just this once?"

I encounter this situation often enough that I developed an approach for my clients, which I'll describe below.  Just recently, the PCI Council addressed this issue in their Assessor's Newsletter.  That perspective, too, we'll explore.  The fact that the Council feels the need to address this issue should at least make readers of this blog feel they are not alone.  

Let's start by defining PCI scope.  You can think of your scope as being in two parts.  The first part is the Cardholder Data Environment (CDE), which includes all the systems, people, and processes that store, process, or transmit cardholder data.  The second part of your PCI scope is any system connected to the CDE.

Most institutions have successfully segmented -- which in PCI-speak means isolated -- their email and administrative systems from the CDE.  However, just when you think you are safe along comes a student, parent, donor, alum, ticket holder, or whoever sending you an email with their card information (and the security code too, just for fun).

Did this kind soul just throw your entire email system into scope?

The answer is: it does not have to.  My advice to clients is that they need to do a few things when this happens.  Here is where annual PCI training comes in to play.  The big thing is that you cannot process the transaction.  If you do, then regardless of any policy you may have, your practice demonstrates that you do indeed use email as a payment channel, so that system is part of your CDE (and every device connected to your email system is in scope...think about that!).

Instead, merchants must purge the email and contact the sender to tell them how they can complete their transaction. If you follow this procedure, you should be able to keep your email system out of scope.  Smart institutions make this part of their annual training to make sure.

Lest you think this is only me talking or that your merchants are the only ones with this problem, read on...

The following is from the June 2012 Assessor Update.  The FAQ of the Month deals with this precise issue:

What should a merchant do if cardholder data is accidentally received via an unintended channel? Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.   In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data. Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include: Implementing controls to prevent acceptance of cardholder data via unsecured channels Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant's CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted. If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant's personnel should be trained to not 'reply' using the same email that contains the cardholder data.  Instead, the merchant's personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data.  This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.  Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant's secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.

There you go.  The best advice directly from the source: delete the data and don't process the transaction.  You may not be able to "patch" your customers, but you can keep them from expanding your PCI scope.

Now, about some of those other t-shirts I've seen...

P2PE Self-Assessment Questionnaire and Program Guide Available

The PCI Council released the latest SAQ for merchants using Point-to-Point Encryption (P2PE).  That SAQ together with the P2PE Program Guide are now on the Council's Documents Library.  You have to spin about half-way down to get to the PCI Point-to-Point Encryption section, but there you'll find both docs and the new AOC.

Before you leap to buy a P2PE solution and complete the SAQ P2PE-HW (no kidding, that's what it is called), make sure you will qualify.  As I forecast (guessed?) this latest SAQ is brief with only 18 questions or control requirements to address.  It focuses on Requirements 9 and 12, but the Council also tossed in parts of Requirement 3 (Protect Cardholder Data) for those who insist on retaining paper forms with PAN data and one part of Requirement 4 so you don't go emailing or texting cleartext PANs.  Actually, as forecast, it is pretty short and sweet.

That SAQ has some pretty strict requirements, though.  Specifically:

• You ONLY process cards using your approved P2PE solution
• You affirm that you are using a solution listed on the Council's website
• You have found and removed any legacy cardholder data from all your systems 
• You implemented the solution per the provider's P2PE Implementation Manual (PIM).

It is that first requirement that may cause some heartburn for merchants who process payments by a number of channels or use different vendors.  My guess is that you will need some decision from your Acquirer on that one.

As everyone knows (or should know), only approved P2PE solutions listed by the Council will count, for this SAQ and for everything.  Right now there are (is?) precisely zero approved solutions.  We can expect to see the first ones later this year and into 2013, so don't go jumping to sign a bunch of contract too soon.

In the meantime, keep monitoring P2PE developments.  This technology has the promise of reducing many merchants' PCI scope and risk (!).  It won't be free, but it could be a good deal in the long run.

P2PE, SIGs, and Other News from the PCI Council

The PCI Council issued their latest Participating Organization newsletter today, June 27.  There is some interesting news here on several fronts that may have an effect on a number of schools.  Here are some of the details.

As most of you know, NACUBO is a Participating Organization in the PCI Security Standards Council.  As one of your representatives, I get a copy of the newsletter and try to share with you -- NACUBO members -- all the latest.  

One of the more interesting pieces of news dealt with the emerging technology, Point to Point Encryption (P2PE).  Tomorrow, June 28, the Council will list both the new P2PE Program Guide and the latest Self-Assessment Questionnaire (SAQ) for P2PE merchants.  I am particularly interested in seeing the SAQ P2PE (or whatever it will be called) to see what it includes.  My guess is that it will focus on requirements 9 (physical security, particularly the POS devices) and 12 (policies).  In fact, there is a good chance that those will be the only requirements.  We'll all see soon.

The P2PE Program Guide will be of great interest to me as a QSA (and part of a P2PE QSA firm!).  This document will list the submission and listing process for P2PE solution providers.  Keep in mind that the only P2PE solutions approved and listed by the PCI Council will count, and only merchants implementing those approved solutions will be able to use SAQ P2PE.  In fact, approved solutions are the only ones you should be considering.

Another important announcement is the opening of the nomination process for 2013 Special Interest Groups (SIGs).  This year, there are  three SIGS -- ecommerce, cloud computing, and risk analysis.  Each SIG is finalizing its report for release later this summer.  Participating Organizations (and QSAs, too!) can nominate topics for a SIG.  My guess is there will be a limit again next year, and I doubt there will be more than three.  If you have any suggestions and your school is a PO, please make them to the Council.  If your school is not a PO, then forward your suggestions either to me (wconway@403labs.com) or my colleague Tom Davis (tdavis@iu.edu), and we'll see if we can toss it in the hopper.

Lastly, the Qualified Integrator and Reseller (QIR) program is getting started.  If you have a payment application that is installed or maintained by a system integrator or reseller, this program is important to you.  Make sure your installer or integrator or reseller is trained by the PCI Council and approved.  This program makes sure you get what you pay for: your PA-DSS application installed properly and according to the vendor's PA-DSS Implementation Guide.  It's your money and your risk, and I personally am a huge fan of this program.  It won't rid the industry of the bad players, but it may help you find the good ones.

Lastly, if you missed the Council's guidance on implementing mobile payments, you can click here to download a copy.

Over One Million Records Compromised in a Few Weeks

Is there something in the water?

In the past few weeks we have seen over a million records containing personally identifiable information (PII) compromised in data security breaches at Higher Education institutions nationwide.  These are very high profile and damaging breaches.

First we read about the University of Maine being hacked.  That relatively small breach netter somebody 1175 Social Security Nubmers and 435 payment cards.  However, it was followed almost immediately by news that hackers successfully stole 350,000 personal records from the University of North Carolina at Charlotte.

Now during this Memorial Day weekend, we learn that hackers executed a "sophisticated and skilled attack" on the university's systems to grab 654,000 student and alumni records from the University of Nebraska.  The data in that breach included "Social Security numbers, as well as addresses, grades, transcripts, and housing and financial aid information. The database also includes information for alumni as far back as the spring of 1985, as well as for people who applied to the university but did not attend school there.

I doubt there is any relation between these data breaches except for one thing: the schools kept a lot of PII (sometimes including payment cards) and they didn't protect it adequately.  

The unfortunate part of all these situations is that they were and remain unnecessary.  PCI is not perfect, but it is prescriptive.  That is, it gives you rules for protecting all you confidential information, not just payment cards.  I have no insights into any of the data breaches noted above except what I read (which, of course, is always dangerous).  But I wonder if the controllers, foundation and development departments, and others responsible for the data followed some simple rules to protect the data?  

For example:

• Did they restrict access to the data to only those staff with a business need-to-know (PCI Requirement 7)?  
• Did they encrypt the data in the database (Requirement 3)?  
• Was there an effective firewall separating the database from the Internet (Requirement 1)? 
• Did all users have strong passwords, and did they use two-factor authentication when accessing the data remotely (Requirement 8)?  
• And maybe most of all, how effectively were the PII databases segmented from the rest of the university's environment (Requirement "0")?

I don't know if these three breaches are the beginning of a trend.  Hoever, now may be a good time for everyone to look at PCI and what it can do to protect all of your institution's PII and keep you out of the headlines for reasons you really don't want to be there.

Guidance on Mobile POS Devices

The PCI Council has just released some very interesting (and brief, hence the "at a glance" designation) guidance on mobile payment devices and applications.  The document is quite interesting, and I recommend it to everyone who is looking at mobile devices for their campus for what it says and what it hints is coming.  I think that should include about every campus on the planet (and every retailer, too).

The Council acknowledges what we already know, namely that mobile payments are convenient and risky.  Therefore, the plan is to encrypt the card data at the swipe before it gets to the device so the phone is "out of scope."  To keep the phone out of scope, though, you need an "approved" card reader and a P2PE Solution Provider.

Er...an "approved secure card reader"and "P2PE solution provider"?

The problem, of course, is there are precious few (if any) approved card readers, and absolutely no approved P2PE solution providers.  Those P2PE solution providers won't be available until this fall at the earliest.  Nevertheless, the PCI Council has pointed the way forward: forget putting a payment app on your iPhone, iPad, Android, or other device; and forget a card swipe dongle (of any shape or make) unless and/or until it is on the PCI PTS list.  The idea seems to be that any smartphone is going to be too risky for a merchant to use as a POS (or Point of Interaction, POI, in P2PE-speak) device.  

I have to wonder whether the many "sleds" that encrypt card data and are PTS certified would still count.  They should qualify as secure readers, but the problem is they go to the processor, and none of them is "approved" yet.  Darn, just as I was really getting to be a fan of the sleds.

Reading the PCI tea leaves is always risky, but here goes...  I predict that any number of things are going to be focused on P2PE, including mobile payments and a re-thinking of the (famous) PCI Frequently Asked Question 10359.  That is the one that says encrypted data are out of your scope so long as the ability to decrypt exists with a separate entity.  This poor FAQ has been stretched beyond its original intent.  I predict P2PE is going to both (a) be the only -- only! -- way to handle mobile transactions using an i-device, and (b) that the FAQ is going to be re-written to specify the only way to keep encrypted data out of scope is to have an approved P2PE solution.

This whole P2PE situation will be interesting to observe, and I suggest everyone involved with PCI monitor developments closely.  At the recent PCI workshop, we had an outstanding presentation and extended discussion of how to handle the growing business need for mobile payments.  I only wish this document was available earlier.  It begins to bring together so much of what we heard, both on mobile and P2PE.

At the EDUCAUSE Security Professionals Conference this week, I did a half-day session on P2PE and tokenization.  We covered a lot, but we only touched on mobile payments.  I have to admit that I didn't see this coming, but I should have.  It is so logical and completely in line with the direction the PCI Council is going.  That is, that personal smartphones are inherently insecure, so merchants need to keep them out of scope.  We all know that.  Except in this case, it took a little PCI wake-up call for me to get it.

PCI Certification Program for Application Resellers and System Integrators

There is great news for every campus merchant who has a PA-DSS application installed and maintained by a reseller or system integrator.  The PCI Council is launching a training and certification program on PCI standards and the importance of correct implementation and installation of PA-DSS validated applications to make sure that the merchant stays PCI compliant.

The new program - called Qualified Implementer and Reseller, or QIR - is aimed at those implementers and resellers of payment application software.

The program applies to all kinds of PA-DSS applications, from food service to parking lots.  While many of these resellers and integrators are doing an excellent job, some have been challenged with installing and configuring the payment applications securely.  The result in some cases has been a data breach that leaves the merchant in an unfortunate position.

The Council expects to launch this course in mid-summer.  There will be more information coming, so watch this space!  In the meantime, if you use a system reseller or integrator, have a word with them about the QIR program.  They, too, will want to monitor developments.

Tokenization and P2PE at EDUCAUSE

I am excited to again join EDUCAUSE at their 2012 Security Professionals Conference (May 15-17). On Tuesday afternoon May 15, I'll lead a three and one-half hour session (whew!) covering two very important and timely topics: tokenization and point-to-point encryption.

Many schools are exploring and in some cases implementing one or both technologies. Both offer the potential to reduce PCI scope, often significantly. However there are a lot of details in the implementation to get all the benefits you hoped for. This is particularly the case with point-to-point encryption where the standards are and infrastructure are still evolving. In spite of this, many institutions are investing in new POS hardware and processes. During the session we'll take a deep dive into each technology and explore what you need to know to implement either/both successfully at your institution.

I don't know if I or anyone has all the answers, but we'll try to make sure we address as many of the questions as we can.

If these topics are of interest to you or your school, and if you are attending EDUCAUSE's conference (or someone from your institution is attending), I hope you will register for this session. We will address both of these topics briefly at the Treasury Institute's PCI DSS Workshop, but this session will let us delve into each topic in some depth.

Paper Data Breaches Can Be Expensive...and Stupid

Has there ever been a more meaningless, patronizing, and pathetic comment made after a cardholder data security breach than: "We take patients’ [or customers'] information very seriously, and we’re reviewing our policy, and our training procedures to make sure this never happens again?"

According to this report from the Boston Globe, St. Elizabeth's Medical Center is currently notifying more than 6,800 people that they potentially compromised billing information, including credit card numbers and security codes. It happened when documents the hospital planned to shred were removed by a vendor from a building scheduled for demolition. Unfortunately, the papers (or at least some of them) containing the PANs and security codes (and probably names, too) were found blowing across a nearby field.

Where do we even begin to go through the mistakes this institution is reported to have made, none of which is excusable?

Let's start with keeping PAN data on paper records. PCI allows you to do this, but you need to protect the data. Here, the mistake probably was keeping the data in the first place. I'm pretty sure the hospital could live with just keeping the last four digits, but they kept -- and then managed to lose -- the full PAN.

Then, the hospital also reportedly kept the 3-digit security codes. For this, ignorance can no longer be an excuse. PCI explicitly prohibits retaining the security codes. If they are on a paper form, then you have to find a way to physically get rid of them. Sadly, the same helpful people who decided to keep the PAN apparently also decided they should keep the security codes, too.

How did the papers get lost? The hospital hired "certain trusted vendors" to clear out a building and shred the paper. It looks like the vendor took some shortcuts and never bothered shredding all the records. You may have noticed by now that nowhere have I mentioned the name of this third party. The reason is that it does not matter: the breach was the hospital's. Just like with any service provider, a merchant can outsource a function, but they cannot outsource responsibility. Rarely has this principle been more clearly illustrated than in this unfortunate breach.

Maybe the hospital will get lucky and only those few papers blowing through the field were lost. This situation is possible. Regardless, the hospital has to pay to notify all 6,831 patients as well as any other expenses. If there is any good news in this mess, it appears that no medical information was lost, so the hospital faces only fines from the payment brands and not HIPAA-related fines.

The lesson for all your cashier, bursar, auxiliary, medical, parking, and other campus departments on that take cards and keep cardholder data is that they are doing the PCI equivalent of juggling razor blades. The PCI team must challenge why they are keeping the data in the first place. Merchants need to be sure they are not storing any sensitive authentication data like the security codes. Then, merchants have to realize that they cannot dodge responsibility for securing the data at all times, including on the way to the shredder. That low-priced bidder is carrying the institution's reputation (and checkbook!), so merchants need to continue to treat the data as their own (which they are). Lastly, do me a favor and please check your Incident Response Plan so you don't issue the usual pandering press release. Telling your customer/victims how much you value them just sounds too much like the incongruous "your call is important to us" we hear as we enter customer service voice mail hell.

Paper cardholder data can be breached just as easily as electronic cardholder data. This is a good lesson. It may be painfully learned in some cases, but a good lesson nevertheless.

MasterCard Guidance on Hosted Payment Pages

One of the best and most common ways to reduce your PCI scope for ecommerce transactions is to use a hosted payment page using a PCI compliant service provider. But a hosted payment page (sometimes called a hosted order page) is not a silver bullet. It does not cause PCI to go away, but it can reduce your scope and cost of PCI compliance.

Recently MasterCard has published a PCI White Paper: Hosted Payment Pages. That document describes how these hosted payment pages work. Just as importantly, the white paper describes the risks merchants still face even after outsourcing. Two of these are man-in-the-middle (MITM) attacks (where the bad guys come between your site and your hosting provider) and phishing attacks aimed at the cardholder's computer.

MasterCard recommends remediation actions (especially for MITM attacks) including regular external vulnerability scans of your server, keeping current with security patches, and developing your code securely. As a QSA, I find it disappointing that the PCI Council's SAQ A does not require any of these actions. Please don't let that fact keep you from securing your ecommerce sites. The SAQs are a guide. You still need to be secure.

I recommend you download MasterCard's paper. It reinforces the earlier bulletin from Visa Europe that I've mentioned earlier.

Visa Suspends Global Payments

The New York Times reports today that Visa has suspended Global Payments after Friday's reports of a significant data breach. You can find reports of the breach all over the Web (here, here, and here).

If you use Global Payments for your card processing, here are a few things to keep in mind. First, the Visa suspension is temporary, and not permanent (at least, so far). Also, MasterCard has not acted similarly (again, at least so far). Get in touch with your representative and find out what are their plans.

Because Visa has removed Global Payments from their list of service providers does not make your institution non-compliant with PCI. It does, however, reinforce the importance of your having the protections of Requirement 12.8 (especially 12.8.2) in place.

Meanwhile, monitor the Web for further developments. This story broke on Friday, and it has grown over the weekend. It is quite likely more developments will be coming.

PCI and March Madness?

What would it look like if we had a March Madness tournament for colleges and universities, but instead of putting the ball through a hoop, we counted the size (number of breached records) of security breaches? The picture would not be pretty, and this is definitely one tournament where you do not want to have your school anywhere near the "final four."

The people at TeamSHATTER just put out a grid illustrating the largest data breaches at higher ed institutions in 2011, and they did it in a very interesting and entertaining (if that's possible) way. They put the schools into brackets and traced the "competition" all the way to the unfortunate winner. You can see their analysis here. As they turned "National Bracket Day" into "National Breach Day."

The unfortunate winner was Virginia Commonwealth University, followed by the University of Wisconsin-Milwaukee, Yale, and University of South Carolina.

What is missing is the larger picture: the number of reported data breaches is down sharply. Fewer breaches were reported (48 in 2011 vs. 57 in 2010), making it harder to fill in the brackets. But the really BIG news is that the number of compromised records fell by a whopping 70% to about 480,000 in 2011 as opposed to 1.7 million in 2010. That certainly is good news.

To be fair to this year's "winner," their breach of 177,000 records while significant, would not make the top 10 since 2005.

Does the decline in overall breaches mean higher ed IT and Treasury departments and PCI teams are doing a better job. I tend to think so. So if you don't see your school on the bracket, congratulate yourself, but don't get complacent. We are already seeing some sizable breaches by schools this year.

If you are interested in more history, you can checkout the figures for previous years also here at TeamSHATTER's site.

Get Your Comments In -- PCI Feedback Period Ends Soon

I want to remind everyone that the PCI Feedback period concludes in March. If you have comments on any of the requirements in PCI v 2.0, if you would like clarification on any requirement, or if there are changes you would like to see, please get your comments to me either via a comment on this blog or email to me (wconway@403labs.com) or Tom Davis (tdavis@iu.edu).

NACUBO is a Participating Organization, and it is in every Higher Education institution's interest to have your voice heard.

Give it a thought, and get back to either of us. We look forward to hearing from you.

Drink Water

Going to RSA?

If you don't understand the question, then you don't realize this is Security Woodstock...I think I just dated myself. Security geeks from around the planet gather for one week in San Francisco. Oh yes...along with every vendor in this space, most of which are sponsoring parties and alcohol-fueled gatherings...all of which I do my best to skip. Well, most of them, anyway.

If you will be there, let me know and let's meet up. Also, whether you want to see my smiling face or not, see this for a guide and guidance.

And to everyone else, if you wonder why I'm not responding to emails or phone calls, now you know!

Physical Security Matters, Too

I have a couple of very nice brief cases that I've collected over the years. There is the Coach one I sometimes use, and the rather nice (!) Ferragamo one I bought in London that always gets compliments, and the standby LandsEnd (actually, about the third as the others wore out or died happy deaths of very old age). But I find these days with airplanes that resemble third-world busses and my need to carry my laptop and assorted toys, that I'm using my backpack while the beautiful briefcases gather dust.

Good thing.

If you don't believe me, read this description of a "security breach" in Paris. Seems the guy had sensitive papers in his briefcase, and got distracted in a train station. The result is the bad guys got away with his company's papers.

I wonder if they just wanted the (high end) briefcase?

My backpack is looking better and better...at least I don't set it down either while buying train tickets or rescuing damsels in distress. Oh yes, it's encrypted, too.

Your Service Provider Contracts

I have long been a bit of a stickler on managing your PCI service providers. Many of you, my clients, know that. In particular, I truly believe that PCI Requirement 12.8 is your friend. Now I have company...the Federal Trade Commission, of all people.

For those of you who are not familiar with each PCI requirement, 12.8 and its four subsections address how you manage your PCI service providers. Service providers are organizations who either store, process, or transmit cardholder data for you or who can affect the security of your transaction (e.g., managed services providers).

In particular, PCI Requirement 12.8.2 stipulates that you have "a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess." That bit about being "responsible for the security of cardholder data" is the important part as the FTC found out in its own way.

You may have heard that the group called Anonymous hacked the FTC's computers recently. According to this article in Dark Reading,

The sites in question were developed by public relations firm Fleishman-Hilliard, which hosted the sites on resources provided by hosting and cloud services provider Media Temple. The two firms are currently duking it out in a very public finger-pointing spat reported by Ars Technica, which also brought to light the fact that the $1.5 million contract to develop the sites initially included security provisions during the acquisition process but then dropped those requirements. [emphasis added]

I'll let you read the entire article, but the lesson is that you don't want something like that to happen to your school's ecommerce or other hosted sites. PCI 12.8 was put there to protect you, and you want to be sure to follow it. And above all, don't negotiate-out any security provisions or guarantees.

You also might want to include PCI compliance language in all your contracts for third party merchants on campus like bookstores, food service, craft fairs, the circus (really!) or other entertainment providers. It's your institution's brand that is at risk, and as I've said before, PCI is your friend.

PCI at EDUCAUSE Security Professionals Conference

PCI will feature prominently when EDUCAUSE holds its 2012 Security Professionals Conference in Indianapolis May 15-17. This is a fantastic gathering of Higher Ed security professionals from around the country. I am pleased (and honored!) to say that I will participate again this year, presenting what I hope will be a very informative and current topic: How Tokenization and Point-to-Point Encryption Can Reduce Your School's PCI Scope. This will be a 3-hour exploration of these technologies and how they might apply.

If you or someone from your institution is attending, please have them consider signing up for this session. When I presented last year, we had a packed room with a great audience who had lots of questions. I am looking forward to the same experience this year.

Another PCI-related session is Seminar 01-A is Navigating the PCI Jungle by Tammy Clark, CISO at Georga State. It will deliver a "common-sense approach to developing a cost-effective and efficient PCI compliance review program at your institution." This seminar is in the morning, while mine is in the afternoon so there is no conflict if anyone wants to overdose on PCI the whole day. Actually, the two are complementary. (Don't tell anyone, but I am planning to try and sneak in to this one, and see what I can learn.)

I look forward to seeing some of you at EDUCAUSE in May.

Is PayPal in Scope for PCI...Maybe!

Everybody knows that PCI only applies to card transactions on the five major card brands (Amex, Discover, JCB, MasterCard, and Visa), right? Well, maybe not. There might be situations where PayPal transaction could be included in your PCI scope. Read on to see what I mean.

Many (although not all) PayPal accounts link back to an underlying payment card. Therefore, the PayPal transaction in many cases will trigger a transaction on the underlying Visa, MasterCard, or whatever. This situation looks to me a lot like a "high-value token" as defined by the PCI Council in their Tokenization Guidance document. Specifically, a high-value token is one that "could potentially be 'monetized' or used to generate fraudulent transactions." That definition sure sounds like a PayPal transaction to me.

The Council's guidance goes on to suggest that tokens "that can be used to initiate a transaction might be in scope for PCI DSS, even if they cannot directly be used to retrieve PAN or other cardholder data."

Combining these two thoughts -- that PayPal might be considered high-value tokens, and that high-value tokens are in scope for PCI -- leads me to ask the question: When are PayPal transactions in scope?

I explored this topic in more detail in my regular column at StorefrontBacktalk.com exploring the circumstances under which I as a QSA might consider PayPal transactions to be in scope for PCI. Like all my columns at StorefrontBacktalk, this one is free so you can click here to have a look (at least for the week or so after it is published). You might also want to read a follow-up column with more details on the Home Depot pilot program.

How will this affect your campus? I don't know. Right now, I'm mainly posing the question and I'd appreciate any feedback. There are some good comments on my column (be sure to read those, too) that generally support the concept that these transactions might be in scope.

If you have campus merchants that take PayPal, you might want to give this idea a thought when you consider your PCI scoping and compliance validation. You also should include it in your PCI training for campus merchants.

pcAnywhere Users Alert -- Patch Now!

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

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

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

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.