Visa's Keylogger Alert

Visa recently issued a security bulletin alerting merchants to an increase in keylogging attacks. you can download a pdf of the bulletin here.

Your users can download keyloggers from an infected email (usually an attachment or a link to a malicious website), a USB drive or CD someone sent you (or you borrowed...bad boy/girl!), or even directly installed by an insider with access to the victim's computer.

Visa states that:

The particular key logger malware identified by Visa is equipped to send payment card data to a fixed e-mail or IP address accessible to the hacker. In these instances, the hacker is able to install key logger malware on the point of sale (POS) system due to insecure remote access and poor network configuration. Based on Visa’s review of the malware, it uses File Transfer Protocol (FTP) and Simple Mail Transfer Protocol (SMTP) on default ports (20, 21 and 25 respectively) to send data out of the network.

The bulletin goes on to suggest a number of mitigation strategies.

BTW, for those of you who think you are immune or that no one would want your banking credentials, you obviously haven't read my previous warning. If that's not enough, you can check out Krebs on Security's latest example of bad things happening to good people.

Download the bulletin and think about your user training. The web is a dangerous place.

Credit Card Pricing: Do You Check Your Statements?

While I mostly deal with PCI and PCI-related issues, the topic of acquirer pricing does come up occasionally. Today I saw an article about payment card pricing that I think is worth your consideration.

The topic is whether you are better off with 'interchange plus' (quick answer: yes you are) pricing as opposed to 'tiered pricing.' Some acquirers are better than others at passing along to you the best pricing. Indeed, there is a mini-industry that has sprouted up to examine your monthly merchant statement(s) and see if you have had inappropriately downgraded (i.e., more expensive) transactions.

As you consider processors, make sure you tell them you want interchange plus pricing. Also work with them to make sure you don't have a lot of transaction downgrades. I have often started a PCI project by performing a payments analysis, that is, looking at transactions by brand and by interchange type. This helps me understand all the different payment channels in use as well as providing a good overview of the school's card business. I frequently see lots of MOTO and other card-not-present transactions at higher interchange rates than I would expect.

Take a look. Then look at your monthly merchant statement and make sure you are getting all that you are paying for...and not paying too high a price.

Hotels and Data Breaches

As I've noted before (see here and here), if your school has a hotel - whether you run and operate it or your outsource it - that hotel can cause PCI compliance challenges. This article in WSJ Online confirms that hotels are particularly vulnerable to data breaches.

As you map out your compliance strategy and approaches, keep it in mind.

The PCI Council Speaks

Fellow blogger and good friend Anton Chuvakin (aka, Security Warrior) managed to score an exclusive interview with Bob Russo and Troy Leach of the PCI Council while at the RSA Conference. (I think I'm hurt...Bob only talked informally to me.) Click here to read it.

In the interview Bob (General Manager, PCI Security Standards Council) and Troy (Chief Technology Officer) make a number of good points about the need for merchants to be educated about what PCI is and how it can protect them. They also rightfully emphasize that security of your systems and data is paramount.

I found a couple of things particularly interesting. First, they seemed to dismiss my forecast that the revised PCI standard will require automated data discovery tools. Darn; missed that one. Another suggestion that I and others have pondered is the development of tiered compliance requirements, maybe one for small merchants and another for larger ones; or maybe one for merchants and one for processors. Bob and Troy knock that one down, sadly, but with good justification. I still think the idea has merit and ought to be explored.

Here's your bonus. Both Anton and Bob will be keynote speakers at the Treasury Institute's PCI Workshop in May. Maybe this time you can be the one to score an exclusive interview with one or both of them! Registration is open (shameless plug...).

Your Policies, Follow-up

There is a great post at Security Catalyst on why you need a privacy policy. It covers a lot of territory and compliments my previous posts (part 1, part 2, and part 3).

Here's the rationale/reasoning...

So to summarize, here are the 7 reasons you need a privacy policy:

1. If you have customers or employees, you need to safeguard personal information.
2. Laws do not usually establish Privacy Practices. Privacy Policies create Privacy Practices.
3. Privacy Policies are often required by law or regulation.
4. Your business faces privacy challenges which nobody else faces.
5. Cloud Computing, Social Media, Goods and Services, Employer, and other activities pose unique challenges to handling personal information.
6. You must comply with specific regulations if you have customers or employees in specific states or the EU, or if your servers (or the servers of a subcontractor) reside in the EU.
7. Your company has affirmative privacy obligations with respect to minors under 13 years old.

Perhaps my favorite part is describing policies not as a "necessary evil," but just "necessary." Have a read, then take a look at how your institution is handling access to social media, iPhones, and all other forms of information including (ahem...) payments.

Is Your Schools' Bank Account About to be Emptied?

If you don't follow Brian Krebs' blog, you ought to. He has posted a series of reports (the latest is here) of small and medium sized companies having their bank accounts emptied by fraudulent wire transfers. The culprit is the Zeus Trojan.

I talked about this attack vector at the Treasury Institute's recent Symposium. Some people felt they didn't need to worry since they have dual authorization on wire transfers. That may be the case, but please, please protect yourself from this attack by isolating any computer used to transfer funds. That is, don't use it to check your Facebook page or surf the net...EVER!

So far a number of small companies have been victims, their money disappearing to the Ukraine and other spots. The wire transfer companies got their fees so they don't care, and your bank will likely blame you - possibly with some good reason.

You don't want to join the ranks of Zeus victims.

Call Center Recordings - Version 3

Yesterday (Feb 17) the PCI Council re-revised their call center FAQ with more clarification on whether you may store digital recordings containing the security codes (CVV2, CVC2, etc.).

Here is the text of the FAQ (link here). The first two paragraphs are the explanation that the Council heard the issues from their previous clarification (see here) just a couple of weeks ago. The next two paragraphs are unchanged:

PCI SSC FAQ’s are designed to provide merchants, assessors, acquirers and other Council stakeholders with clear and timely guidance on PCI standards. They are a critical two way communication channel from which the PCI SSC draws valuable market feedback and insight, and is able to share this with the industry. On January 22 2010, as part of the online FAQ feedback and submission process, the regular
review of FAQ language, and inquiries from Participating Organizations the SSC sought to clarify its position on call center audio recordings.

The updates to the FAQ language were intended to eliminate any inconsistencies in implementations of audio recordings in call center environments by providing a higher level of specificity in FAQ guidance. The Council’s position remains that if you can digitally query sensitive authentication data (SAD) contained within audio recordings - if SAD is easily accessible - then it must not be stored. As a result of additional market feedback, on February 17, 2010 the SSC modified the new language to further clarify its position on audio recordings. Please find this language below:

This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

Now this is where it gets interesting. The phrase "if that data can be queried" is new, and the Council emphasized (bolded) it. This sentence in the previous FAQ ended here. Storage of digital recordings was verboten, period. Now, it looks like there may be some room. The paragraph after is some good advice.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried [Council's emphasis]; recognizing that multiple tools exist that potentially could query a variety of digital recordings.

Where technology exists to prevent recording of these data elements, such technology should be enabled.

The final paragraphs are also changed. Where previously the only exceptions to recordings containing the security codes were analog tapes (as if anybody still used them), now there is much greater leeway. The new FAQ - or FAQ v3 as I call it - now says you can keep the digital recordings so long as you protect them per PCI. The last paragraph is simply recognition that sovereign law supercedes PCI:

If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.

This requirement does not supersede local or regional laws that may govern the retention of audio recordings.

Where does this leave us. Let me try and summarize:

• Call centers can now store digital recordings containing sensitive authentication data like the security codes. Yesterday they couldn't. Last year they couldn't.
  
  
• The PCI Council got sufficient market feedback from the previous FAQ that they took the issue back to the Technical Working Group and the 5 brands. The result is this revised position.
  
  
• Up to this time, the only exception to the rule prohibiting storing the security codes was for system testing, and that had to be tightly controlled. Now call centers can retain tons of digital recordings and protect them per PCI. BTW, if you do this don't even dream of using a simplified SAQ!
  
  
• There are bound to be questions about what it means to have records that "cannot be data mined." Will this mean encryption? Maybe. Does it mean keeping the data offline? Possibly. Should you restrict access? Plan on it. In fact, if you have these recordings I'd plan on getting some expert guidance to make sure not only that you are compliant, but that you are secure!
  

For more information, see this column in StorefrontBacktalk (full disclosure: as you know, I am PCI columnist for SFBT).