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!