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).

PCI Training

Getting good PCI training is critical for anyone involved in getting their campus(es) compliant with PCI DSS. As most of you know (I hope!) the Treasury Institute offers a 3-day PCI Workshop annually. The next one will be May 3-5 this year in Indianapolis (click here to learn more). The Institute has also offered a 1-day PCI Workshop twice.

The PCI Council offers 2-day PCI training based on the course required for each Qualified Security Assessor (QSA). According to the Council:

This is a 2-day training course based directly on the PCI SSC Qualified Security Assessor (QSA) training program. Attendees will learn what the QSAs learn so they can better prepare for an on-site PCI DSS assessment or perform the assessment internally. This is not a certification course.

The course will cover: PCI Program, Scoping a PCI DSS Assessment, PCI DSS v1.2 Requirements and Compensating Controls

You can learn more and get the current schedule here on the Council's website.

The two programs are different. The Institute's workshop is focused on the unique needs of Higher Education and it features case studies and great networking with other schools. The Council's training is very technical in nature and provides a wider perspective on issues across industries and possible approaches.

Visa used to offer a 2-day course also modeled on QSA training, but I don't see that on their website currently. If you are interested in this, check with your acquiring bank. They have to register you anyway.

You could arrange for a PCI trainer to come to your campus and conduct customized training for you. This can have cost advantages since it minimizes travel and registration costs. You also can have different staff attend those parts more appropriate to their jobs. I've seen great examples at individual schools who make it part of a "security day." It can also work well for groups of schools that are part of a common university system.

Whatever way - or ways - you choose, compare costs, compare approaches, and get yourself trained. It pays great dividends.

Compromise of Chip Cards

There is a lot of buzz in the security world over the successful compromise of some European chip cards. A group of Cambridge University researchers demonstrated that they could trick a terminal into authorizing a transaction even though they did not know the PIN. In other words, they managed to convince the chip card that they had a signature-based transaction while they simultaneously convinced the POS terminal that it had a PIN-based transaction. They could put in any PIN and the transaction was authorized.

There have been past instances where researchers have compromised a chip cards, that is, payment cards with an embedded microchip. The idea is that each time the card is used the cardholder has to enter their PIN. Where the system doesn't add much security is when the card is not present (mail, phone, and e-commerce transactions), or when either the chip is damaged or a non-chip card is presented when the terminal reverts to signature mode.

Chip-and-PIN can reduce card-present fraud. No one argues with that. But it is not a silver bullet that will make PCI go away or even make it less relevant.

If you want to see this compromise in action, click here to see the broadcast on the BBC.

New PCI Call Center Recording Rules

If your Development department (or anyone else on campus) records phone transactions, you need to take a look at the PCI Council's revised FAQ on these recordings. You may need to upgrade or replace your recording system or, failing that, stop call recording altogether.

The issue is recordings that include card security codes, e.g., CVV2, CVC2. Many Development and Advancement departments record complete donor calls during phone-a-thons. These recordings have always been in scope for PCI, but if they were not searchable you could keep the security codes, too. This amounted to a free pass for Requirement 3.2 which states you may not store any sensitive authentication data.

The free pass was revoked January 22 when the Council issued a revised FAQ on call center recordings. The Council stated:

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

The Council's reasoning was:

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors.

What does this mean? If you have a digital voice recording system, you will need to purge all your old recordings of the security codes. Then you need to configure/upgrade/replace your call recording system not to record these codes on all new recordings.

The Council carved out a minor exception for analog or tape recordings since these are not searchable. It reinforced, however, that even these recordings are in scope for PCI.

To see the complete FAQ go here. Then take a look at your IT budget to see if you have a line for new/upgraded call center recording software. Then again, maybe you don't need those recordings after all.

Changes for PCI In October: "No Surprises"

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

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

"End-to-end encryption is a catchphrase because at a certain point along the line, the data needs to be decrypted," prompting key management questions, Russo said. "Key management introduces a whole new series of issues that could cause you to be less secure."

Russo said he doesn't expect an end-to-end encryption special interest group will study the issue. Instead encryption within the payment process will be addressed when other technologies that affect the payment process are identified and studied. The Virtualization Special Interest Group, due to recommend guidance in March on protecting card data within virtualized environments, will address the role of encryption as well, Russo said.

"Unfortunately there are so many different technologies that merchants may have started down the path with that we need to be careful and study them before prescribing them in the standard," Russo said.

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

Cost of Data Breach Study Updated

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

Some of the highlights of the study are:

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

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