MasterCard Revises L2 Validation Requirements

If your school has any Level 2 merchants, you might benefit from changes in MasterCard’s merchant level definitions (see here).

If you have a Level 2 merchant for Visa, they are also L2 for MasterCard. Under MasterCard's rules introduced this summer, L2s will need to complete an onsite assessment by a QSA. The original deadline was December 31, 2010.

As of yesterday, the new effective date is June 30, 2011. MasterCard is allowing 6 more months for Level 2 merchants and their processors to make the transition.

There's more.

The original requirement was for a QSA to prepare a Report on Compliance (ROC), but that, too, has been modified to give you an option of using your Internal Audit staff provided:

“[T]hat primary internal auditor staff engaged in validating PCI DSS compliance attend PCI SSC-offered merchant training programs and pass any PCI SSC associated accreditation program annually in order to continue to use internal auditors.”

This means that while Level 2 merchants need an onsite assessment, they have the of using their Council-trained internal audit staff to conduct their onsite assessment if they choose.

The good news is MasterCard cut some major slack by moving back the effective date 6 months, and they re-instituted the option of having internal audit staff conduct the onsite.

I still have some open questions, and I'll continue to follow developments. For example:

• If an internal auditor performs the onsite, must they follow the same guidelines as a QSA in preparing the ROC?
  
  
• Can an internal auditor use an SAQ or even a simplified SAQ? The wording on the website is unclear.
  
  
• Will the Council review internal auditors’ ROCs (or SAQs) as they do with QSAs?
  
  
• Will Visa implement similar requirements?

I personally give lots of credit to MasterCard for listening to merchants (they didn't have to!) and being willing to respond to the needs of merchants and acquirers by extending the deadline. At least they gave more time for L2 merchants to respond and gave them the option of using their internal audit staff.

Now it is up to merchants and their acquirers to implement the changes smoothly.

Attack of the Christmas Greeting Cards

The following warning appeared on the SANS Storm Center. Ignore it at your peril!

With the holiday season upon us, lots of folks (me included) have elected to send online greeting cards instead of using traditional paper cards, "saving" the carbon and emissions footprint involved in traditional mail services (not that email is carbon free or anything, but that's a whole other discussion).

Just a word of warning - as happens every year, fake greeting cards are being circulated via email, with malware payloads attached. We got our first reader email on this today, Daniel received a greeting card with a ".net" at the tail end of a legitimate domain. The attackers even went to the trouble of making their site look like the real one! These attacks use more sophisticated phishing techniques every year, and the malware payloads are of course also more difficult to detect each time.

So if you get a greeting card, even if it's from someone you know, be sure that the link you click is taking you where you expect to go. Check that the link is to a reputable greeting card site, and that it doesn't have "extra" characters at the end, that would indicate you are going someplace else entirely. Even better, "don't click that link!" - copy and paste it into your browser rather than clicking it directly, that way you have that much more assurance that you know where you are browsing to.

Have a safe, malware-free holiday everyone !

New PCI Column

Those of you who know me know that I have written a number of articles for publication in addition to this Higher Ed PCI blog. This is to let you know that I have started writing a weekly (eek!) PCI column for StorefrontBacktalk.com.

My premier effort was this column on in-scope vs. out-of-scope data for PCI. It followed an interview I did the previous week. I've since written about MasterCard's new validation requirements for L2 merchants, and travel/purchasing cards. This week's column should be out soon.

I hope you'll add SFBT to your bookmarks or RSS feed. Evan Schuman covers a range of retail-focused card issues, many of which apply to Higher Ed, too. And besides, it gives you another chance to take shots at me and/or my opinions!

I am taking over for good friend Dave Taylor who passed away so suddenly and so unexpectedly last month. Dave set a very high standard for the weekly PCI column, and I will try my best to keep up. In my own way, this is sort of a continuing tribute to Dave.

Meanwhile, everything will continue as usual here at the Treasury Institute blog. Wish me luck!

The PCI Knowledge Base Continues

As most of you know, David Taylor, founder of the PCI Knowledge Base, died this past October. His work, the PCI Knowledge Base lives on. The website and discusison forums are continuing. Stop by. Search some of the great webinars and check out the continuing flow of new content. And stay tuned for additional developments.

PCI Compliance...at a Discount!

Good friend Anton Chuvakin (aka, Security Warrior) along with co-author Branden Williams have released their book "PCI Compliance." If you go to Anton's website (click here) you will see a discount code good for 30% off the price and a link to the website to purchase a copy.

I haven't seen the book, but I have my own copy coming. Given the experience and expertise of the authors, it's a can't miss.

PCI Council Webinar Next Week Open to All

The PCI Security Standards Council is inviting all payment industry stakeholders -- yes, that includes YOU -- to attend their next “Open Mic” webinar. Typically, these sessions are reserved for Participating Organizations, but (maybe as a holiday present?) the Council is making this one open to all.

The two webinars will held on Tuesday December 8 at 3:00 p.m. ET and Wednesday, December 9 at 11:00 a.m. ET. PCI SSC General Manager Bob Russo will host the session providing a brief update on PCI SSC initiatives, followed by a live Q&A session. The update will cover the Community Meeting, next steps in the lifecycle process to revise and update the DSS, and some recently published resources on the Council's website.

To register for the Tuesday, December 8 session, use this link.

To register for the Wednesday, December 9 session, use this link.

I hope a lot of you will register and attend one of (both?) these webinars. I'd like to encourage the Council's commendable efforts to reach out to the broader PCI community beyond just the Participating Organizations.

Campus - and Personal - Security for the Holidays

I recommend you take a look at Linda McGlasson's post 'Tis the Season for Thieving. There is some good advice for all, both for your campus security (check out the warnings on fake bank transfers) and your and your staff's personal security (phishing, fake charity websites, etc.).

Some specific scams Linda offers highlights includes:

Holiday e-cards (loaded with nasty attachments)
Fake "new friend" emails
Unsecured public terminals (do you really want to use a password at that kiosk!?!)
Fake holiday websites (Santa really, really would not go there)

May we all have a safe and secure holiday season...but somehow I sort of doubt it.

Your School Needs Another Domain

I saw this post at the ha.ckers.org site describing how a particular domain name - com.com - was up for sale. While that might be in itself interesting to you or not, one part of that post caught my attention:

In fact, one of C|NET’s (the company that currently runs com.com) network admins was listed as the 10th most dangerous and least likely person on the Internet during my presentation at OWASP. Why? Because of typo traffic. A friend of mine used to run csuchico.com instead of csuchico.edu and used to get tons of sensitive information about the local college, including building plans, love letters, medical information, bills, and on and on… And that was just one .edu domain. Now imagine the typo traffic for all of .com!

I remember when I was with a small company, we had not only our .com address, but we also got the .net, .org, .edu, and every other "dot" domain we could. Why? For the same reason as CSU Chico should have: people make typos and send all kinds of stuff to the wrong domain. And that's just the innocent mistakes. You certainly don't want a bad guy spoofing your site using the same name but different domain.

Moral of the story. I'm sure most of you have already done this, but if you haven't go out and spend a few bucks and get all the domains for your school's name and not just the .edu. It won't cost much and it may help you sleep better. And if you find someone is already camping on the domain, well I guess maybe that tells you something, too...and you should not like it.

PCI Update in NACUBO's Business Officer

The November issue of NACUBO's Business Officer is out with a report from Tom Davis and me on the PCI Community Meeting. You can see it here once its online. Golly, we even got featured on the cover, and they included our pictures at the end. FYI, Tom's the better looking one; I'm the one with (some) hair.

I blogged about the Community Meeting before (particularly here and here), but the Business Officer article gave us a chance to go into more detail and report in more organized fashion. I was also pleased that NACUBO included a link to the blog as well as our respective email addresses.

What's the point? The editors got it right away, and they highlighed it in box: PCI is being revised next year, and it is effective October 2010. That means you want to take advantage of the NACUBO-Treasury Institute partnership to stay informed and monitor developments. They will doubtless impact your campus and your job. Thanks to Matt Hamill and Carole Schweitzer at NACUBO for helping spread the word through the Business Officer.

Is Your Campus Hotel Targeted?

If you have a hotel on your campus, you should have a look at Visa's Alert on Targeted Hospitality Industry Vulnerabilities. I've blogged about campus hotel PCI issues before (see here and here), but this release highlights two particular attack vectors that should get your attention.

In one case, hackers in which they install debugging software on POS systems to extract full magnetic stripe data from volatile terminal memory. As Visa explains, this method of data
extraction from memory is of particular concern since unencrypted data is commonly written to volatile memory during the transaction process. Best of all, hackers may utilize tools to execute the program remotely.

Another attack is when which hackers with full access to the system enable debug mode on payment applications to obtain full magnetic stripe data from the system. For this type of attack, debugging software is not necessary since the payment application has the option to enable debug mode for troubleshooting purposes. A solution is to ensure you set administrative and all privileges properly.

Hotels are a particularly challenging PCI environment. They also are, apparently, targeted. Don't wait to be a victim. Act now to ensure you and your institution are protected.

Visa Issues FAQ on its Payment Application Mandates

Visa just released a FAQ on its payment application mandates. Visa issued the mandates with two objectives in mind:

• To eliminate the use of payment applications that are known to be vulnerable to attack or that store prohibited data like the security codes or PINs; and
• To require merchants who use third party payment applications to use only PA-DSS applications.

Note that if you use an internally-developed payment application (does anybody still do that!?!), the second part of this mandate doesn't apply to you. But if like most of the Higher Ed world you use third-party apps that store, process, or transmit payment card data, then those apps have to be PA-DSS compliant. And the only way you can tell is to go to the list on the PCI Council's website and check to see if your app is listed. While you're there, be sure to check the version and expiry date, too.

I'm sometimes asked if using a PA-DSS application makes a school PCI compliant. The answer is a firm NO, but it can help if you do it right. First, your PA-DSS app has to be installed according to the vendor's Implementation Guide (you asked to see a copy before you signed up, right...we could have a major discussion on that one), and you installed the app in a PCI compliant environment. Then the best you can say is that the PA-DSS app won't be the cause of your being non-compliant. In other words, PA-DSS apps can simplify your compliance effort considerably, but they are not a panacea.

This FAQ is intended for you. There is nothing particularly new, but it is a good reminder of some important upcoming dates you need to be aware of. This is just one of the topics we'll be discussing at the upcoming Treasury Institute PCI Workshop in Long Beach this January. I hope you will be able to join me there.

OWASP Top Ten for 2010 Released

Late today (Friday) a preliminary update to the OWASP 10 for 2010 was released (click here). As most of you know, PCI compliance requires (among a bunch of other things...) that all custom code be reviewed so as not to be vulnerable to these exploits.

There are some changes in ranking. A couple of new candidates are on this preliminary list:

• Security misconfiguration (in the #6 slot) had appeared in the 2004 list, but was dropped in 2007; and
  
• Unvalidated redirects and forwards (#8) which is new to the list.

The latter is relatively unknown and can cause significant damage.

The two that were dropped are:

• Malicious file execution (was #3) which is less prevalent today; and
  
• Information leakage and improper error handling (was #6) which while still common has less impact.
  

The proposed list is open to comment through December, and we can expect it to be finalized in January 2010. The timing is particularly opportune as the revision to the Top 10 comes in time to be reflected in the upcoming PCI DSS release this fall.

Processor Best Practices You Can Use

Visa just released its Cardholder Data Security Best Practices for VisaNet Processors. I think there are some things in this document that you as merchants can use, too. Here are a few examples with my comments/observations:

• Entities should identify their organization’s lines of business as well as the processes involved in storing, processing and/or transmitting cardholder data. By accurately identifying all business processes that handle cardholder data, processors can better define the scope of the cardholder data environment and ensure its adequate protection.
  

  Great advice for everyone: document your payment process and minimize PCI scope. In my world, this is "PCI Requirement 0", meaning you should do this before you even start to attack the entirety of the DSS.

  
  
• Truncate cardholders’ primary account number (PAN) when business processes do not require use of the full PAN.
  

  Truncation takes the data out of scope. And why are you saving the full PAN anyway? For more, consider...
  

• Support unique identifier tokens (e.g., a Visa Transaction ID is used in some
  regions) for recurring payments and dispute resolutions, thereby eliminating
  merchants’ storage of PAN data and reducing scope for acquirer processing
  systems where use of the full PAN is unnecessary.
  

  Bingo! In my experience, there are two frequently-cited and equally unnecessary reasons schools and other merchants retain PANs. One reason is recurring payments, and as Visa notes, you don't need to keep the PAN for these. The other reason is chargeback processing which, again, doesn't require you store the PAN. You say your processor doesn't support this? I say ask them again, and if you still can't get a straight answer get a new processor.

• Entrust a security champion at the senior executive level to lead the organization’s data security efforts, including the development and maintenance of the security policy and its strict adherence across the organization. Senior executive management (e.g., Chief Information Officer, Chief Technology Officer or Chief Information Security Officer) should be central to the oversight of the organization’s data security policies, programs and procedures.
  

  Senior management commitment is critical to PCI implementation and your security. This goes for merchants and processors.

• Perform vulnerability scans and penetration tests more frequently than required by the PCI DSS for critical resources (e.g., monthly, weekly or more often). Scan all resources including networks, systems, applications, databases, services and components for vulnerabilities and perform penetration tests to determine the effectiveness of current security controls.
  

  Scanning is a low-cost way of letting you sleep better at night. Check out how much (little?) it will cost to go from quarterly to more frequent scans. You might be pleasantly surprised.

• VNPs should not solely rely upon an annual assessment by a QSA to identify where cardholder data is being handled or to uncover any lapses in security controls. Instead, third party assessments completed by a QSA should support the VNP’s existing security programs and regular internal reviews.
  

  This is another way of saying PCI copliance doesn't make you secure.
  

There is other good stuff there. Download it, read it, and maybe even share it with your processor...

A Personal Note

I hope you will allow me this personal blog post, but I learned today that David Taylor of the PCI Knowledge Base passed away suddenly Tuesday. Dave was a friend and colleague. I was privileged to know and work with Dave. He built the PCI Knowledge Base after a distinguished career at Gartner. Many of you may also know Dave from his not-to-be-missed weekly post at StorefrontBacktalk where he offered factual and often irreverant (Dave had a great sense of humor) observations on PCI in the retail world.

I first met Dave about 3 years ago at RSA. We hit it off and he asked me to help out in a small way on the PCI Knowledge Base. Dave and I did a couple of webinars together, and each was an experience. We never rehearsed as such, but we discussed our talking points, who would talk when, and agreed on the general flow. I never knew why we did this prep since once we started, Dave went off on whatever topic or thought or whim he felt was important...and his instincts always turned out better than my plan.

I shall miss Dave a lot. We saw each other too briefly at the PCI Community Meeting in September, and we spoke just a couple of weeks ago, making plans for him to speak at the Treasury Institute's PCI Workshop this spring. We also talked about general PCI developments and emerging technologies. As always I learned something new.

The world doesn't produce a lot of David Taylors. We are the poorer for that, and we are even more the poorer for his passing.

Is Your Web App Secure? Really?

The Web Application Security Consortium (WASC) today announced the findings of its WASC Web Application Security Statistics Project 2008. Their objective was to pool data from a number of sources to assess the vulnerability of web applications across the Internet.

WASC's analysis of over 12,000 web applications is disturbing. Some of their findings are [WASC's emphasis]:

• About 49% of web applications contain vulnerabilities of high risk level (Urgent and Critical) detected during automatic scanning
• Detailed manual and automated assessment by white box method allows to detect these high risk level vulnerabilities with probability up to 80-96%
• The probability to detect vulnerabilities with risk level more than medium (PCI DSS compliance level) is more than 86% by any method
• At the same time, detailed analysis shows that 99% of web applications are not compliant with PCI DSS standard.
  

So...let's see here... About half of all web apps have high risk vulnerabilities, it's pretty straightforward to detect the vulnerabilities with automated scanning, yet 99% of web apps are not PCI DSS compliant.

Concerned yet?

Now, these data are from 2008 so they may be a bit old, and I don't know that all the web apps examined were payment apps (!), so maybe the 99% figure is high. Nevertheless, I have to believe the PCI Council will have a comment on this report and its findings.

Keeping Informed

One of the hardest parts about payments and PCI is keeping informed of new developments, state laws, emerging threat vectors, and ideas about what may be coming. You are already making a start by reading this blog (c'mon...what did you expect me to say!?!), and I recommend you check out the other blogs I've recommended on the right.

Another source of information is the Society of Payment Security Professionals which publishes The SPSP Wire. This is a monthly newsletter highlighting recent developments (you can register to get it free via email by clicking here). The current edition also has a preview of the upcoming issue of Secure Payments magazine. The Q3 issue of the magazine (available online and soon in print to SPSP members) has my latest article on developing your internal security policies, so it'll be sure to sell out quickly... You might want to check out both. (Usual disclosure: I am on the SPSP Advisory Board, write for the magazine, and with others review potential articles; I have no business interest).

Then again, you could just keep coming back here!

PCI Merchant Levels Cleared or Confused?

Branden Williams writes that Visa and MasterCard have pulled the "reciprocity" from their merchant level definitions (see here). For those of you not up on all the details, I'll try and explain what's going on.

Let's say you have 1 million Visa transactions a year and 500,000 (non-ecommerce) MasterCards (Visa is the larger brand, so this ratio is reasonable). According to Visa you would be a Level 2, and according to MasterCard you would be a Level 4. So far, so good. However, this is where the "reciprocity" part kicks in.

Reciprocity meant that if one brand rated you as a higher merchant level, you would be that higher merchant level for other brands, too. In our case above, while you were a Level 2 (Visa) and a Level 4 (MasterCard) based solely on your card activity, with reciprocity you would be a Level 2 for both brands.

Now in the past the different merchant levels didn't matter a lot since you would pick your SAQ, do your quarterly scans, and that was it for merchant levels. No big deal...until a few months ago, that is.

As I described in a previous blog post, the game changed this summer when MasterCard announced Level 2 merchants would be required (by December 2010) to validate their PCI compliance with an outside assessment by a QSA. Suddenly, reciprocity became a pretty big deal as merchants who didn't have that many MasterCard transactions found that they were required to have an outside assessment because "reciprocity" made them a Level 2 merchant.

Initially, I put this down to the Law of Unintended Consequences. It appears that after thinking it over (and if friend Branden and I are both reading the MasterCard Merchant Levels correctly) MasterCard has removed "reciprocity" from its definitions.

Where does this leave us?

While each of the brands reserves the right to escalate your merchant level based on a breach or their judgement (Any merchant that MasterCard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system), it looks like we are back to counting your transactions by brand and comparing them to the brands' guidelines.

This may...just may...be a case where common sense wins out. I'm sure MasterCard had no plan to snare smaller merchants into a more expensive compliance regime. So if your MasterCard volume makes you a Level 2 merchant, you need to have your validation assessed by a QSA. But it looks like if you were a victim of reciprocity, you may have just dodged a (financial) bullet.

Email Spam Spreading Viruses

For several days I've been monitoring the increasing spread of viral spam that's been spreading. You can check out the latest at SANS Storm Center which is tracking it.

The emails come from all over the world, and they have an attachment or link that users are clicking on. Bad idea.

This may be a good time to warn your users (and yourself...) not to click on any attachments or links in any emails unless they are expecting them. These spam emails are pretty slick purporting to come from your own network administrator. Don't fall for it, and don't let your colleagues fall for it, either.

Operation Phish Phry

How full is the "junk" folder in your email account? If you are like me, it gets filled faster each day with junk email. Most of these emails are simply, well, junk. But some are phishing emails sent by genuine bad guys trying to get me to divulge a password, Social Security Number, account number or other personally identifiable information (PII). We all get these phishing emails, and they are clever.

Yesterday, the FBI announced its Operation Phish Phry. According to the FBI:

The defendants in Operation Phish Phry targeted U.S. banks and victimized hundreds and possibly thousands of account holders by stealing their financial information and using it to transfer about $1.5 million to bogus accounts they controlled. More than 50 individuals in California, Nevada, and North Carolina, and nearly 50 Egyptian citizens have been charged with crimes including computer fraud, conspiracy to commit bank fraud, money laundering, and aggravated identify theft.

In conjunction with this, FBI Director Robert Muller was in San Francisco addressing the Commonwealth Club. His remarks included the following:

Most of us assume we will not be targets of cyber crime. We are not as careful as we know we should be. Let me give you an example.

Not long ago, the head one of our nation’s domestic agencies received an e-mail purporting to be from his bank. It looked perfectly legitimate, and asked him to verify some information. He started to follow the instructions, but then realized this might not be such a good idea.

It turned out that he was just a few clicks away from falling into a classic Internet “phishing” scam—“phishing” with a “P-H.” This is someone who spends a good deal of his professional life warning others about the perils of cyber crime. Yet he barely caught himself in time.

He definitely should have known better. I can say this with certainty, because it was me.

After changing all our passwords, I tried to pass the incident off to my wife as a “teachable moment.” To which she replied: “It is not my teachable moment. However, it is our money. No more Internet banking for you!”

Wowsers. The head of the FBI is human. And to use his own embarrassing experience to illustrate that we all are at risk shows me he is also a pretty big man.

At the upcoming PCI Workshop in Long Beach (also a link on your right), I planned a little phishing exercise. It may not be Operation Phish Phry, but I think it will open your eyes a little to the risks in your email inbox.

Phishing should be part of your user training. Read Director Muller's remarks and see how you can use this information in your own internal training.

Your Campus Hotel and PCI

I have been working with and talking to a number of schools recently that operate hotels on campus. These hotel operations face particular PCI compliance challenges due to the nature of the hotel business. That is, they hold lots of cardholder data like the PAN for reservations (and to charge you that $2 for the bottle of water from the minibar...), and they even retain (occasionally intentionally) security codes (CVV2/CVC2). Therefore, these operations can forget using any of the simplified SAQs; they get to use SAQ D or, if they are big enough, they require an outside assessment by a QSA.

I saw this article today on PCI compliance in the hotel/hospitality/resort industry, and I thought I'd pass it along to all of you. The author seems to know the industry, and his advice fits with my own experience. Some of the specific suggestions (and my comments) are:

• Are users automatically logged off after a maximum 10 - 15 minutes (max) of inactivity? (This is a good practice...actually, 10 minutes seems pretty long. Better yet, make sure this applies to all terminals throughout the property...yes, even Housekeeping.)
  
  
• Is all card holder data in folios, receipts and reports masked with maximum 4 - 6 digits appearing? (Masking is good and should be used for all reports and screens except in very few cases. This is spelled out in PCI. If masking is good, truncation would be even better.)
  
  
• Is card holder data masked or encrypted within the database? (PCI requires that all cardholder data be rendered unreadable. Usually, this means encryption. I'd add here that encryption is a good start, but restricting who has access to the data -- also mandated by PCI -- is pretty important too. BTW, did I mention all the fun you now get to have with the rest of Requirement 3 like key management...?)
  
  
• Is track data or card verification codes encrypted within the database? (OMG! OK, OK, I'm calming down...sort of. If you keep the security codes, don't encrypt them...PURGE THEM. These codes are sensitive authentication data and you are not to retain them; ever; no, really: ever.)
  
  

As you are working on PCI compliance on your campus, take a look at that industry's own needs and remember Conway's Laws of PCI: Law 1 - your costs have gone up, so deal with it; Law 2 - you will change the way you do business.

Read the article.

POS PIN-entry Vulnerabilities

Those of you with PIN-entry devices (PEDs) at your point of sale (POS) should take a look at Visa's POS PIN Entry Device Vulnerabilities white paper out today.

Visa reports on the increasing number of thefts of PEDs from merchant stores. The theft is bad enough, but the devices are being replaced by modified (read "compromised") devices by the bad guys that skim cards and PINs. Replacing a POS PED can happen fast, in less than a minute.

The paper highlights particular devices that are targets. I suggest you check the list and match it against your own POS inventory. You do have a POS terminal inventory, right...!?!

I happened to run across this first-person article last week that shows how simple this fraud can be, and I also saw a second report here with similar info.

So...get your POS terminal inventory and check it against Visa's advisory. Now.

Visa Best Practices on End-to-End Encryption

Visa has just released a pdf on data field encryption, aka end-to-end encryption. You can download it here.

There has been a lot of interest in this technology which was featured as a potentially game-changing technology at the recent PCI Community Meeting (see here). As the document points out: "Data field encryption protects card information from the swipe to the acquirer processor with no need for the merchant to process or transmit card data in the 'clear.' Importantly, data field encryption renders cardholder data useless to criminals in the event of a merchant data breach."

Visa's best practices are designed to achieve the following security objectives:

• Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.
• Use robust key management solutions consistent with international and/or regional standards.
• Use key-lengths and cryptographic algorithms consistent with international and/or regional standards.
• Protect devices used to perform cryptographic operations against physical/logical compromises.
• Use an alternate account or transaction identifier for business processes that requires the primary account number to be utilized after authorization, such as processing of recurring payments, customer loyalty programs or fraud management.

Visa notes that there are no industry standards yet, and that there is no single technology that can completely solve the fraud problem. They importantly make the point that end-to-end encryption is intended to supplement PCI DSS. Therefore, those of you looking for that single solution - aka silver bullet - solution, I guess you just have to keep on looking.

And for you end-to-end encryption fans, note the title is labeled "Version 1.0"... more to follow? Encryption and conspiracy fans unite!

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

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

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

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

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

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

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

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

• MasterCard won the prize for succinctness: “MasterCard considers these cards in scope.”
  
  
• Discover replied similarly: “Per the requirements of the DISC program, which may be found on our Web site, any payment card bearing the Discover logo is considered to be within scope of the PCI DSS.”

• Visa was the winner in the fastest response sweepstakes. They provided, however, a more nuanced response: “As stated by the PCI DSS, any entity that stores, processes, or transmits cardholder data is within scope. The corporate card data itself would not be within scope of an entity's PCI DSS compliance VALIDATION scope but should be secured in accordance with personally identifiable information restrictions. However, if the entity's corporate card information resides in the same systems or unsegmented network as their merchant payment card processing environment, the systems would be within the entity's PCI DSS compliance VALIDATION scope.” [emphasis is Visa’s, not mine]
  
  I translate this to mean if the corporate card data are housed in the merchant’s cardholder data environment, then and only then would the corporate card data be in scope. Otherwise, treat the data like you treat other sensitive corporate data or PII.

• Amex’ response to me at the PCI Community Meeting was that Amex corporate cards are out of the issuing school's or company’s scope. Amex believes they should not require the company issuer (or any cardholder) to do anything special; it’s up to the issuing company.

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

• Corporate/travel/purchasing cards with the MasterCard and Discover logos are in PCI scope for the issuing school.
  
  
• These same cards with the American Express logo are out of scope for the issuing school.
  
  
• These same cards with the Visa logo are in scope only if the corporate card data are stored in the merchant cardholder data environment.
  

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

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

PCI Community Meeting - Day 2

Day 2 of the PCI Community Meeting is just concluded.

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

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

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

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

PCI Community Meeting - Day 1 at The Listening Meeting

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

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

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

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

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

The first conclusion is that none of them is a silver bullet. Sorry to break your hearts, but there it is. Additionally, there are challenges with all of them, and the challenges are not technical. Rather, the challenges are mainly on the business side. Examples cited were:

• The lack of knowledge and expertise on the part of all parties.
• The lack of consistency across all parties as to the role/appropriateness of the technology. for example, merchants, QSAs, vendors, and even the Council might have different interpretation of the usefulness of the technology.
• The need to change procedures for card acceptance/processing by merchants and processors.
• And somehow making it easier to ensure consistent implementation of the technologies.

The bottom line is that the impact of each of the 4 technologies is likely to be highly variable (translation: no guarantees) depending on how the technology is implemented and the particular environment in which it is implemented. And everyone is still working on making the business case (think ROI), how to integrate the technologies with current merchant and processor environments, and the impact they will have on customers.

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

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

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

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

Tomorrow promises to be another full day.

Off to the PCI Community Meeting!

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

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

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

Being the "Bad Guy"

Are we in the "no" business?

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

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

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

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

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

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

Any and all ideas welcome!

UPDATED: More on Choosing A QSA

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

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

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

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

Real Cost of a Security Breach?

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

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

Lesson one: breaches really are expensive.

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

Procurement Cards Can Be Breached, Too

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

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

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

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

Give it a thought.

40 Years Young and Going Strong

Where were you on September 2, 1969?

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

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

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

I'm a QSA!

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

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

Bob Russo Comments on PCI and Recent Breaches

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

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

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

Remember, it's time to be careful.

Time to be Careful

Today's required reading is an opinion piece in the New York Times "Time to be Afraid of theWeb" The article assesses the current state of Internet security and concludes that you don't have to visit risky sites or really do much of anything out of the ordinary to be at risk. The author concludes:

But with more and more information about people’s credit cards, browsing histories and identities sloshing around online, I wonder whether this will do. A few months ago, I nervously created my first Facebook page with the minimum necessary information to view pictures posted by old friends.

I returned to the page a few days later to discover that somehow it had found out both the name of my college and my graduation class, displaying them under my name. I have not returned since. In the back of my mind, I fear a 28-year-old hacker and a couple of Russians have gathered two more facts about me that I would rather they didn’t have. And it’s way too late to take my life offline.

This opinion piece is a good companion to the excellent article on the Conficker virus in yesterday's Times. For even more background, look to the upper right of this blog and click on the "search the archive" link. Put in "dangerous" or something like that and you can find earlier advice, observations, and maybe a few examples.

Why am I writing this in a PCI blog? Because this is what your students, faculty, and staff are doing. This is where they are surfing on your school's systems. This is where they are collecting malware (like I seem to collect parking lot dings on my car...). And this is why you don't want cardholder data anywhere on your systems. If the data aren't there, they can't be compromised and you can't be in the headlines for reasons you'd prefer not to be.

So... be careful! Spread the word.

Keeping Informed on PCI Just Got Easier

It can be really tough staying on top of developments in PCI DSS, card brand rules, risks, threats, and everything else we are supposed to know about but don't have the time to follow. I have a couple of suggestions.

First, of course, you might want to follow regularly this blog (what did you expect me to say!?!). Also, I've put links to some really great resources on the right hand side. These are blogs I follow, and sometimes refer to them. Now I've got two more for you.

I just found out (thanks, Branden) that Visa has an RSS feed. This one gets my vote for one of the neatest developments in a while. You can sign up for any number of notifications (I picked "Select All", but this is sort of my business, after all...). It is a great way to keep on top of Visa's alerts and bulletins.

I can't wait until I get to tell you about MasterCard or Amex doing the same thing...hint, hint...

The PCI Council also has an RSS feed. Subscribe to it and you can get all the news and announcements. There may be more than you want here, but you may want to check it out.

Keeping informed just got a little easier.

Choosing a QSA...How Do YOU Do It?

Nearly all schools validate their PCI compliance using a Self-Assessment Questionnaire (SAQ). Nevertheless, many schools also hire a QSA to help them in the process, either with training, conducting a PCI gap analysis, designing a compensating control, or just helping the internal team through the process. All of which raises the question: how do you select a QSA?

Do you pick the biggest, the cheapest, the easiest grader, the one who worked with another school you know? For an interesting insight, take a look at good friend Dave Taylor's post at StorefrontBacktalk. Dave takes you through the ups and downs all in a couple of pages.

Full disclosure: I work for a QSA firm. But what I would like to hear is how did YOU chose your QSA? What factors did you consider? What was important to you and your institution? Leave a comment. It won't take long, and we all might benefit from sharing the information.

A Discussion You Might Want to Follow

What can PCI DSS do, and what can it not? What role may it have played or should it have played in the recent breaches?

There is a discussion going on at StorefrontBacktalk that you may want to read...and be sure to read the comments. It deals with the recent breaches and the questions above. Another great take on the indictments and security is at Mike Dahn's blog (which also has a number of links).

Serial Credit Card Thief Indicted

The Justice Department claimed today's indictment of three individuals represent the biggest case of credit card theft ever prosecuted. The one American and two unnamed Russians are charged with stealing over 130 million credit card numbers from all the organizations you've been reading about: Hannaford, 7-Eleven, Heartland Payment Systems, and a couple of others.

In some cases they sold the numbers; other times they used them to buy goods. To me, the big story was the reputed mastermind behind these and other thefts. This guy is already under other indictments for the TJX breach, among others.

Here's the reason I'm bringing this to your attention: these guys targeted their attacks. They actually identified who would be likely to have lots of payment cards, then they systematically went after them.

If this doesn't make you worry, it should.

If this doesn't make you re-think storing PANs electronically, it should.

And...
If this doesn't make you maybe a little more scared of the bad guys and a little less scared of your QSA, it definitely should.

UPDATED: Heartland CEO blames QSAs

I'm not sure I agree with everything that is said, but I recommend you read the article in ComputerWorld (also in CSO) where Heartland Payment Systems CEO Robert Carr talks about their massive data breach.

One good point he does make (which means I agree with him...) is when he says "If a smart person's job is to define a set of rules to keep merchants from being breached and they have to start somewhere, what they come up with is going to look something like PCI. There has to be a lowest-common-denominator set of rules. PCI could be improved, but the standard is fine."

Read the article, and blame who you want to blame or nobody. But keep in mind a few things. This was a processor. They have to retain cardholder data. You are a merchant. You rarely if ever need to retain the data. So go back and ask yourself if keeping cardholder data is really worth the risk and lost sleep.

UPDATE: For a response to Mr. Carr's comments, you have to see this post by Rich Mogull at Securosis. I could not say it better.

MasterCard New PCI Requirements Clarified

MasterCard has posted a 4-page FAQ on its website describing the recent changes to its Site Data Protection (SDP) program. I've blogged about this previously, but now we have some details (with thanks to Branden Williams again).

Here is my take on what it means to you. I'll focus on Level 2 merchants since that is where the changes are.

• If you are a Level 2 merchant, you now need to hire a QSA to conduct and complete an onsite data security assessment by December 31, 2010, and repeat it annually. Forget the idea of using you internal auditors - that option no longer exists. It appears MasterCard has figured out ("I'm shocked, SHOCKED...") that maybe some merchants were a little too liberal with checking the "in place" column in their SAQs.
  
  
• Interestingly, if a L2 merchant outsources their processing to a validated processor, and the merchant would have previously qualified to validate their own compliance with SAQ A, then according to the FAQ they can continue to do so. The rationale is that since the processor has an onsite data security assessment, that covers the requirement. That one sounds like it might be a little inconsistent to me, but I'll leave it to the folks at MasterCard and the acquirers to work it out.
  
  
• There is an interesting point in the FAQ about "newly acquired merchants." MasterCard seems to be taking a page from Visa's playbook and requiring that acquirers only "board merchants that are PCI compliant." So much for shopping around and changing acquirers to avoid compliance...
  

There's more in the FAQ, but the message is clear. If you are a Level 2 merchant, it's time to start looking for a QSA, which you can do by following this link to the PCI Council's website.

BTW, the FAQ says all this information went out to MasterCard acquirers on June 15. Hmmm...let's see...it's now August and people are just finding out about this. But of course, all of you heard about this in June from your acquirer, right...?

PCI DSS v1.2.1

Most of you know that NACUBO in partnership with the Treasury Institute is a participating organization in the PCI Council. One of the benefits to you is that we (meaning "you") get the latest news from the Council directly. One such example is the email I got today from the Council on version 1.2.1 of the PCI DSS.

I mention this only so that if you go to the Council's website and download some of the publications, you will see this new version number. Don't get too excited or concerned: there are no changes to the standard as detailed in the FAQ I received:

The move from version 1.2 to version 1.2.1 of the PCI Security Standards Council’s Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS) signifies minor corrections designed to create more clarity and consistency among the standards and supporting documents. The changes are minor, for example; correcting spelling, eliminating redundant lines and updating language to synch with supporting documents. [emphasis added] There are no additions to the requirements or to the intention of the standards. This change, and the creation of DSS, PA-DSS, and the PA-DSS Program Guide 1.2.1 is administrative in nature.

Each document has been updated with a table of changes on the front page illustrating precisely where the administrative updates have been made within the document.

Additional information in the Council's FAQ includes:

Should I revisit my compliance plans or implementation timelines?
As there are no changes to the intention or requirements of the DSS, your compliance programs will be unaffected by the change from DSS 1.2 to DSS 1.2.1

Do I need to do anything differently?
You should continue to work with your assessor on your current compliance program. There are no changes from v1.2 to DSS 1.2.1.

Does this change your plans to roll out the next version of the PCI DSS?
This will not affect the planned, public lifecycle of the DSS. We are currently in the feedback period of the lifecycle and encourage organizations to share feedback with us through the online feedback form, FAQ tool and direct email contact. The first feedback period runs until November 1st and incorporates both the US and European Community Meetings.

So...if you download any documents from the Council, don't be put off by the new version number.

Welcome Back, Mike!

Mike Dahn has a new blog, and I suggest you might want to follow it. Mike brings an unique blend of experience (former QSA trainer) and expertise to his PCI DSS rants...er, I mean posts. Today's post is no exception...and I agree with every word of it.

Welcome back to the blogosphere, Mike.

MasterCard Goes Public with Noncompliance Fines

Here is something I've been following for the past week or so, and I want to make sure you know about. According to Branden Williams' blog, MasterCard has instituted a schedule of fines for Level 1-3 merchants who are not compliant. The fines are quarterly, they escalate, and they continue until you validate compliance:

-- Levels 1 & 2: $25K first quarter; $50K second quarter; $100K third quarter; $200K fourth quarter.

-- Level 3: $10K first quarter; $20K second quarter; $40K third quarter; $80K fourth quarter.

Add it up. If you are a L3 merchant and it takes you a year to get compliant, you might need to add about $80K to your budget for the fines.

There is more here and here.

Most of you may remember Visa'a Compliance Acceleration Program which was a set of financial incentives and penalties to get L1-3 merchants compliant. Now MasterCard has joined the act in a big way.

I can't find anything at MasterCard's SDP site. I understand that the details went out in a letter to acquirers. So I recommend that you follow-up with your acquirer and see if this new policy affects your school.

Meanwhile I'll be monitoring developments and pass along what I learn.

Chip Cards for the US? Maybe Not Soon

I saw an interesting post at Glenbrook's Payments News blog that might interest some of you. As most of you know, almost all payment cards (Visa, MasterCard, etc) issued in Europe have an imbedded computer chip. The chip -- hence the term, chip card -- is read at the time of transaction, the cardholder types their PIN (not "PIN number"...) into the terminal, and if all goes well the transaction is approved. American card don't have these chips, but no big deal: the card terminals also have a mag stripe reader so you can buy that nice dinner in Paris or go to the opera in Berlin.

The interesting news is that The European Payments Council is apparently considering a ban on mag stripe cards. Personally, I don't think this will happen anytime soon, or at least I hope not.

The creditcards.com article is a good overview of the situation. If you are interested in chip cards or travel to Europe, you might find it interesting.

So, when do I think the US will go to chip cards like most of the rest of the world? Don't hold your breath for all the reasons spelled out in the article.

Why You Don’t Surf the Web on Payment Workstations

Some clients have asked me why I’m such a pain in the ___ (insert your favorite body part here) about letting them use their workstations to enter card transactions. I’ll give you the answer: it is so you remain safe. Here’s an example why…

I was reading in the recent article in Dark Reading about a new Trojan called Clampi that is specifically targeted at businesses like yours. It is designed specifically to identify and steal financial information. The Trojan is incredibly sophisticated, seeking out and collecting administrator credentials and financial account data. It has already been used to execute successful thefts by transferring funds.

Want to know how good this thing is? The criminals behind it are not selling it to other less sophisticated bad guys as is the usual case. No; this thing is so good they are keeping it just for themselves. I don’t know about you, but that part particularly scares me.

How do you protect yourself? Anti-virus programs won’t be much help. This Trojan hides itself pretty well, plus it detects which AV product you use and takes steps to avoid being found. An intrusion protection system (IPS) can help, but they’ll probably find a way around that pretty soon.

Is this beginning to sound like swine flu meets Friday 13th in a train wreck???

The best way to avoid it is to assume the worst: do not use any computer you use for financial transactions to surf the web. And yes, I mean that even if you use a white list. An expert quoted in the article said: "Using Windows, it's too dangerous to do transactions on the same machine you do for Web surfing. You can't have any crossover between them."

That’s why I tell my clients – and I’m telling you – do not permit web surfing or email on any machine you use for card transactions. Period. That includes cashiers, finance staff who process exception items, development fund raisers, hotel front desk clerks…anybody. Somebody reminded me this week of the old line: just because you’re paranoid, that doesn’t mean they really aren’t out to get you. In this case “they” are the bad guys – criminals. And they really, really are out to get you. Don’t make it easier for them.

Network Solutions Data Breach

If you use Network Solutions for your card processing, you should read this. It is possible that thousands of merchants and unknown numbers of cardholders will be affected. According to thecompany:

In the ordinary course of business, Network Solutions identified unauthorized code on servers supporting some of our E-Commerce merchants’ websites. We promptly removed this code, and all of our E-Commerce servers are functioning properly. No servers supporting networksolutions.com were affected.

After conducting an analysis with the assistance of outside experts, we determined that the unauthorized code may have been used to transfer data on certain transactions for approximately 4,343 of our more than 10,000 merchant websites to servers outside the company. On July 13, 2009, we were informed by our outside forensic experts that the data being transferred may have included credit card information. The code may have captured transaction data from approximately 573,928 cardholders for certain periods this spring

This breach is sure to re-ignite the "Compliant when Compromised" argument -- Network Solutions claims they were PCI compliant at the time of the breach (see here).

We all should recognize that at this time we don't know everything, but if you think you might be affected check out the Network Solutions statement.

Welcome to the New Site!

This is the new site for the Treasury Institute's PCI blog. Please update your bookmarks to point to this page. No changes to the management, just a new shop location. You can still search through all the past blog posts on the previous site. I've repeated some recent posts below.

Long Beach PCI Workshop in January

On Wednesday, January 27, the Treasury Institute will hold a 1-day PCI workshop in Long Beach, California. We have timed the PCI workshop to coincide with the Institute's Symposium 2010.

I will lead the workshop. I'm still developing the agenda, so your thoughts and input are welcome. The focus will be PCI implementation strategies and issues. I plan to offer some brief case studies based on my work with a number of schools to illustrate some common PCI pitfalls and how to avoid them. The session will be a great learning and networking opportunity, particularly for many western and west coast schools that could not travel to Indianapolis last May. The workshop is designed for anyone on campus who is actively involved in or responsible for PCI compliance.

You can learn more about the workshop and even register online by clicking here. I look forward to seeing many of you there!

Phishing Attack Foiled

(Originally published July 16,2009)
I have seen a lot of clever and some not-so-clever phishing scams. I just saw the following in the Chronicle's Wired Campus:

After business hours last Thursday night, an e-mail message popped into the in boxes of 800 people at North Carolina State University with the subject line “Mandatory Security Update: July 2009.” The e-mail message, which claimed to be from the IT Help Desk, said that in an effort to block spam, all e-mail users had to click a link to the university’s e-mail sign-in page and enter their user name and password.

It seemed perfectly normal — the image icons were the same, and links to the home page and directory all looked fine.

But it was all a hoax.

While this attack may not be the most original, the response by North Carolina State was outstanding. They stopped the attack before any real damage could be done. Then they realized something else. The phishers had such a good-looking site because they were copying the actual graphics from the school's own site. So, guess what? They changed the graphics to say "THIS IS A PHISHING SITE. Do not enter your password".

These guys at NC State are rock stars! For a complete rundown with copies of the NC State response, visit their site which also gives a complete blow-by-blow of their actions.

And you thought they were only good at basketball!

PCI Wireless Special Interest Group Reports

(Originally published July 16,2009)
For those of you who use wireless networks in your payment environment, the PCI Council's Wireless Special Interest Group has this afternoon released their Wireless Guidelines. If wireless networks figure in your payment environment, I suggest youdownload the report and give it a good read...all 33 pages of it.

I'm still digesting it, so maybe I'll have some comments later. Right now, it looks pretty comprehensive.

PCI and Your Third-Party Service Providers – Now Some Good News

(Originally published July 16,2009)
I wrote (ranted…?) last time about working with schools and their non-validated service providers. I focused on some disappointing if not downright misleading behavior by a few providers. Now, I’d like to share some more pleasant news: more and more service providers are getting validated.

In one case the school was using a non-validated service provider. That is, the service provider wasn’t on Visa’s list. When we contacted the provider, they knew exactly what we were asking about, and they sent a document describing their plan to become a Level 1 Service Provider, complete with timetable and identifying their QSA firm. They had made substantial progress and hoped to be validated within weeks. Clearly these folks had been thinking about this for a while.

In another case we spoke to the vendor who ended up giving us (!) a little lecture on the importance of PCI. Then he displayed a pretty thoughtful insight: from his point of view, he wanted to outsource the payment process, too. This vendor would maintain all their functionality (which the user loved) but outsource the payment part of it. They had already built links to a number of other payment vendors so the school could choose one to which they were already connected. If you recall my earlier blog post on SunGard, I really endorse this approach for both schools and service providers. Besides, when the service provider offers a solution like that, it can make the consultant look pretty smart, too. (I wonder if I remembered to thank him...)

There is good news on the payment application front, too. More Higher Education application providers are going through the PA-DSS validation process. In fact there are so many apps on that list currently that I recently had to download it to Excel so I could search through it. Others are working on providing a hosted solution which can go a very long way to helping a school become compliant. Again, my personal preference is to get the payment processing out of the school’s PCI scope and outsourced to a validated processor that does this for a living. I see this direction as (hopefully) a trend.

To summarize, there is good news on the third-party provider front. These days, I’m encountering more vendors who “get it” with PCI. They realize that PCI isn’t going away, and that their customers are not going to stay with a supplier who will not support a school’s own compliance efforts. It makes my life easier, too: nobody wants to tell a client to stop using an application they have been happy with for years.

My compliments to all you service providers who are validated and to those who are getting close. Good job! For the rest of you service providers…did I mention I can suggest a good PA-QSA firm…?(end of shameless promotion).

PCI and Your Third-Party Service Providers – First, the Bad News

(Originally published July 10,2009)
It’s happening again. I’ve now run into it a couple of times in the past few weeks. I’m working with a university to get them PCI compliant. Somebody on campus is using a third-party service provider that is not on Visa’s list of compliant service providers .

My usual procedure (and what I recommend to you) is to get the vendor on the phone and say something like; “I notice you are not on the list of PCI-compliant service providers; what are your plans to get on the list?” Then stop. Let them talk. Many times the vendor is well aware of the situation, and they will happily share their plans with you. But oh, those other times...

Twice recently I’ve had a vendor submit their scanning report. Like that’s supposed to make me feel warm and fuzzy that they’re compliant!?! That says they passed a scan by an ASV. Whoopee. When I see this, red flags go up. How about the rest of PCI compliance, like almost the entirety of PCI DSS? If they process more than 300,000 transactions a year – and you do not want to deal with any service provider who doesn’t – they are a Level 1 service provider and they need a QSA to sign-off on their Attestation of Compliance. Where is that Attestation of Compliance? Is it current?

My favorite is when the vendor replies that they are compliant as a Level 3 (or 2 or whatever) merchant. That response is completely irrelevant and inexcusably misleading. That they are compliant as a merchant is meaningless to you when you use them as a service provider. They can self-assess as a merchant – they cannot as a Level 1 service provider. That extra step is meant to protect you. If you get that kind of reply, you are likely dealing with an over-eager and/or ill-informed sales rep…ask to talk to an adult.

What about all your small vendors that serve a market niche? Do they need to be compliant? Yes, they do, and it will cause some of them to find another business. PCI effectively eliminates small vendors that can’t afford to become and stay compliant. While sad in for the vendor, it is better your school. You don’t want to entrust your brand and your financial data to an unsecure, vulnerable outside vendor.

But there is a lot of good news. That’s in the next post.

PCI Feedback Begins Today!

(Originally Published July 7,2009)
The PCI Council is soliciting feedback on the current version of PCI DSS. Per the Council:

The open feedback period regarding the PCI Data Security Standard (DSS) v 1.2 and Payment Application Data Security Standard (PA-DSS) v. 1.2 begins today! As part of the Council's transparent, standards management lifecycle process, you, our Participating Organizations - merchants, processors, financial institutions, associations, vendors, and other key stakeholders - have the opportunity to provide detailed and actionable feedback in an effort to revise future editions of the Council's standards to improve payment data security. This is part of phase two of the lifecycle process and the feedback period will be open from July 1 to November 1, 2009.

Thanks to NACUBO and the Treasury Institute, you have a voice through Tom Davis and me. We are asked to comment on no more than 5 items that are the most important. Tom and I each have ideas on what these might be, but we both would like to hear what you think.

Any and all comments welcome. Comment here directly or send me an email (walt@walterconway.com) with your suggestions. Please limit yourself to your top few ideas/comments. Tom and I will pull things together and provide our (your!?!) feedback to the Council.

One of the great advantages of being part of a Participating Organization is that we get to help shape the Standards. This is your chance to make your voice heard.

MasterCard PCI Validation Requirements and You

(Originally published June 26,2009)
If you are a Level 2 merchant (or have one on campus) then the new MasterCard validation requirements affect you.

Rather than repeat what has already been said, written, or blogged about, I'll refer you to Branden Williams' blog. He has been following the issue closely and has some good insights.

I don't know how many of you are affected by this change, but if you are, feel free to contact me directly with any questions.

I Want Your Input To the PCI Council

(Originally published 6/26/09)
As all of you likely know, NACUBO (in partnership with the Treasury Institute) is a Participating Organization in the PCI Council. I along with Tom Davis at Indiana University are NACUBO's representatives, and therefore represent all of you in Higher Ed at the Council's Community Meetings and other forums. In that role, I received the following email from Bob Russo at the Council:

One of the most important aspects of my role as General Manager for the PCI Security Standards Council is communicating with you, our Participating Organizations, about our standards and how we can help you secure your customers' and clients' cardholder data. That said, we've recently created a survey to assist us in gaining your feedback because your input drives the direction of the standards.

Your answers will play a big part in helping us to enhance payment account data security around the globe. However, please note that the data you provide will only be analyzed in the aggregate; your individual responses will be kept confidential.

Thank you for taking the time to share your opinions with us!

OK...now it's up to you. What would you like me to say? What constructive suggestions do you have? What changes to the PCI Standards would help you secure your students', parents', donors' and friends' information?

You can let me know by commenting or just send me an email: walt@walterconway.com. Please get your thoughts to me by July 2.

Thanks!