Shopping with Virtual Credit Cards (VCCs)

by Scott Chapman

I’ve been using virtual credit cards (VCCs) for online shopping, phone shopping, and bill paying for almost a decade now. So it amazes me that most of my friends have never heard of VCCs or the virtues of VCCs.

What’s a VCC? VCCs are virtual credit cards generated on demand for you by your credit card company either via an app on your computer or via your credit card company’s website. Each VCC contains the following information:

• VCC number – a valid, temporary credit card number different from your physical credit card number (PCC)
• Card Verification Value (CVV) - a 3 or 4 digit number, commonly found on the back of a PCC,that’s unique to the generated VCC
• Expiration date - the VCC’s expiration date, which typically can be controlled by you
• Spending limit – the maximum amount that can becharged to this VCC (obviously, all charges to all VCCs in addition to thecharges to your PCC cannot exceed your PCC’s limit)

Since VCCs are “virtual,” no PCCs will be created and mailed to you by your credit card company. This is because VCCs exist only in electronic form.

Here’s an example of how VCCs work:

When I shop online, I typically generate a separate VCC for each transaction, limiting the VCC to a short, two month or less expiration date. When the VCC is charged by the website retailer, the VCC becomes locked to that retailer so that no other retailers can charge to that VCC. This implies that if the VCC is stolen from the retailer’s database, the thief will not be able to use the VCC anywhere except at the retailer where I used it and only if it’s stolen and used prior to the VCCs expiration. In addition, my credit card company allows me to individually cancel each VCC using a single mouse click, so if I’m feeling really paranoid about a retailer, I can quickly cancel the VCC within a short period of time after the retailer charges the VCC. The retailer still receives its money, but the card becomes invalid forany further charges (or credits).

In addition when I generate a VCC, my credit card company allows me to optionally set a 2 to 12 month expiration period on each VCC and to optionally set a spending limit on each VCC. With these features, I can create VCCs that last 12 months for use on monthly recurring charges, such as paying the cable company bills, the wireless company bills, and charity donations where the amounts are typically the same each month. I can also limit how much the retailer can charge to a VCC. For example, say I donate $100/month to a charity using a PCC. Instead of using a PCC, I can create a VCC that’s valid for 12 months with a spending limit of $1,200and provide this VCC to the charity. At the end of the 12 month period, I can either provide a new VCC to the charity or terminate my contributions.

So basically, VCCs allow you to limit the exposure of your PCC information. They also allow you to control the validity period of your VCC and the amounts charged to your VCC.

One wonderful side effect of VCCs deals with annual recurring subscription charges. For example, charges by magazine retailers to which you no longer want to subscribe. If you give your PCC number to a magazine retailer, every year they’ll charge your PCC number for the annual recurring subscription fee whether you meant to renew your subscription or not. If you use a VCC with a short expiration period of say two months to pay for your subscription, your subscription will only be renewed if you provide the magazine retailer with a new VCC. Now you’re in charge (pun intended) of your subscription renewal, not the subscription company.

There are a few things to be aware of with VCCs. Some companies like Amazon display products from other retailers. Each retailer charges your credit card number separately and, with each order, only one credit card number is required for the purchase. If your order contains products from multiple retailers and you use a VCC, only the first retailer to charge your VCC will succeed because the VCC locks to the first retailer who charges to it. The other retailers will be blocked from charging your VCC. To solve this problem, you’ll need to create a separate order for each retailer and use a separate VCC for each order. Virtual storefronts like Amazon typically have a “sold by” statement near the top of each product description page indicating who the retailer of the product is to aid you when creating your order.

Also, if you buy something online or over the phone that requires you to present your PCC to prove that you’re the actual purchaser (such as for a will call), you’ll need to use your PCC and not a VCC because no physical card is created for a VCC.

VCCs also go by other names such as “single-use credit card numbers,” “one-time use credit card numbers,” “substitute credit card numbers,”“disposable credit card numbers,” and “controlled payment numbers” which you may have heard of in the past. The “one-time use” and “single-use” names may be misnomers as the VCCs generated by my bank can be used multiple times with thesame retailer up until the VCC’s expiration date.

The VCC idea was developed by a company called Orbiscom which was acquired by MasterCard Worldwide in January 2009. The banks that I’m aware of that currently use the Orbiscom system to support VCCs are:

• Bank of America– ShopSafe
• Citibank – Virtual Account Numbers
• Discover Card - Secure Online Account Numbers

There are differences between banks as to how their VCCs work, so your experience may vary compared to the descriptions in this article.

To wrap up, if you want to limit the exposure of your physical credit card and to limit the ability of retailers to make unwanted charges to your credit card, virtual credit cards are a great way to go.

They Don't Sleep at Night - Computer Imps

by Jeff Jilg

I recently saw a neat painting at the 2011 PCI Community Meeting.

The subject of the painting was computer hacking, and the rendering showed a mythical imp with pointy ears. He was bound by cuffs labeled "PCI" and was reading a book on hacking. The artist got it right, and a lot of attendees liked the painting.

Yep, the artist is right. Hackers don't sleep at night. Hackers don't have a time slot to break down computer defenses. They couldn’t care less about when or where the assets are stored. For all they know, they could be hacking into a computer in the same town, or a computer in another country.

And that's the real problem. It's tough to fight such resilient criminals. Technology has made it easy for them to have plenty of potential assets for them to prey upon. The PCI standards do a pretty good job of setting up compliance standards to help stave off the bad guys. As a consumer I feel a bit safer with credit card processing getting more scrutiny.

As many industry pundits have said, "the motivation of the hackers is directly proportional to the assets being protected". atsec supports the PCI standards and atsec is a qualified security assessor company. We like to think we are helping too.

So far I haven't seen any real computer imps. I wonder if they really have pointy ears or not…

The Call of the Conference

by Andreas Fabis

We attend conferences for a variety of reasons. First of all, atsec consultants frequently speak at IT security conferences (e.g. we are presenting four papers at the 2011 ICCC). We want to stay on top of current developments in our field of expertise. Secondly, conferences are a good way to connect with our current and future customers in a personal manner.
If you attend any of the following conferences, we would like an opportunity to talk to you about your IT security, upcoming projects, and the ways we can help you meet your IT security testing, evaluation, compliance, or training needs:

• PCI SSC Community Meeting
  September 21 - 22 2011
  Scottsdale, AZ
• ICCC 2011
  September 27 - 29 2011
  Kuala Lumpur, Malaysia
• LASCON 2011
  October 28 2011
  Austin, TX
• MILCOM 2011
  November 7 - 10 2011
  Baltimore, MD
• ACSAC 2011
  December 5 - 9 2011
  Orlando, FL
• RSA 2012
  February 27 - March 3 2012
  San Francisco, CA
• SXSW Interactive
  March 9 - 13 2012
  Austin, TX

If you can’t catch us at a conference – don’t hesitate to contact us directly.

Complexity and Security

by Robert Hoffmann

The feature-richness of today's information systems and applications has not only led to architectural complexity and difficulties in maintenance, but also provides a large attack surface.

A risk analysis shows that the actual threat is the product of probability and severity. The traditional approach of improving the component's security is therefore offset, if at the same time the accessible interfaces increase at a much higher rate.

As a result of corporate driven philosophies to provide ever more product features and functionality leads to and increasingly worsening situation in today's technology. Instead of relying on trusted components, new components, product versions or even whole new technologies are often deployed in production systems as soon as they are available, resulting in complex architectures and implementations.. Of course the vendors are only partly to blame. It is also the customer who demands more and more advanced products. Only lately have they started to realize that this usually comes at the cost of decreased stability and security.

In September 2010, the German computer magazine c't reported on severe security issues in 17 banking websites. [1] The 16 year old student whom the article is written about, Armin Razmdjou, found several cross site scripting vulnerabilities. Even after the banks patched them up, he still found more. In their desire to provide the best customer experience, the banks were using web technologies that were never designed to provide a secure transaction environment. Combined with the complex layout of their web pages, it led to an application that cannot be considered “secure by design” anymore.

In the fall of 2011, Sony became a target for hackers due to political reasons [2]. Within two months their web servers were hacked 20 times, including disclosure of personal related data. The hackers attacked various local servers in multiple countries to gain access. Instead of “putting all their eggs in one basket,” a complex distributed design was used by Sony. This meant that their information systems exposed a huge attack surface, and a threat from a basically equipped attacker who could exploit just one of the vulnerabilities resulting in a very costly incident.

This problem is not limited to websites, but can be found in a variety of applications and services as a consequence of increasing complexity in systems together with public access to them.

Another example was Vodafone in 2009. Their femtocell product was hacked, allowing an attacker to impersonate and perform a man-in-the-middle-attack on any Vodafone UK customer [3]. This was possible because access to internal cryptographic information was needed by the femtocell to function. While larger base stations are located in a secured area and connected via dedicated lines, the femtocell is set up in the more hostile environment of the customer premises and communicates over the Internet. This meant that many formerly only internal interfaces were now accessible by the customer. There were of course security measures in place, but because the hackers could manipulate the hardware they could also circumvent the software protection.

In this case, a complex device that was never designed to be used externally was suddenly given to the customer, thereby multiplying the attack surface of the whole system.
Traditional approaches, such as penetration testing, might only remind us of the problem. It was already shown in 1974 by Paul Karger in his Multics vulnerability analysis [4] that testing and patching only shows the presence of vulnerabilities, and not their absence.

The security community has recognized this and developed the concept of attack surfaces [5]. By analyzing the attack opportunities, a statement can be made about the security level of a system. This should not be mistaken with “security by obscurity.” Any interface, be it intended to be public or not, is considered as being available to the attacker.
But the problem needs to be approached more fundamentally. Systems need to be designed with security in mind from the beginning. This includes the requirement to minimize both the attack probability and its possible severity.

The UNIX principle of having small components that provide only limited functionality, but do that well and proven, should be used to create building blocks of systems.
By combining such components, it will be possible to create interfaces that expose only the least required functionality and ensure its security. This also keeps the overall design complexity of the system low because only required components are included and active.

Security analysis needs, of course, also have to reflect this. A reactive approach using only penetration testing and subsequent patching techniques is insufficient. Instead the complexity of a system needs to be included in the analysis, as well as the size of the attack surface it exposes. Both need to be treated as the weaknesses they are, and be subject to improvement. Security analysis and testing has to move from a component orientated task to a holistic system evaluation.

Some ideas in this direction in regard to Common Criteria have been suggested by Helmut Kurth at the 10th ICCC in Tromsø:
http://www.atsec.com/downloads/presentations/An_Attack_Surface_Driven.pdf

[1] http://www.heise.de/newsticker/meldung/Banken-Seiten-weiterhin-unsicher-1179476.html
[2] http://blogs.forbes.com/andygreenberg/2011/06/20/in-sonys-20th-breach-in-two-months-hacker-claims-177000-sony-emails-compromised/
[3] http://seclists.org/fulldisclosure/2011/Jul/187
[4] http://csrc.nist.gov/publications/history/karg74.pdf
[5] http://www.cs.cmu.edu/%7Ewing/publications/Howard-Wing03.pdf

atsec Newsletter Published

We published our German newsletter and invite you to take a look. The topics include:

• atsec's impressions from last year's ICCC
  
• Establishing a Certificate Authority
  
• The IEEE Protection Profiles for Multi Function Printers
• atsec at the Datenschutzfachtagung
• Milcom 2010 and AFCEA
  

You can download our newsletter from the atsec website.

Is your Pentester licensed?

by Steve Weingart

Most people don’t know it, but in Texas, any third-party computer security testing (such as penetration testing, forensic imaging or data recovery) where the tester could be exposed to your customer’s data, must be performed by a licensed Texas investigations company.

Not many security testing companies get licensed, but if they are exposed to 3rd party data to an extent that is more than inadvertent, the license is required.



You might think that this sounds crazy, but it actually makes a lot of sense. People who may get access to your (and your customer’s) data should be verified as being honest folks who are not criminals. While most security testing companies routinely perform background checks on their employees,unless your testing company is licensed, you never know for sure .

As part of the process for registering individuals as investigators, the person’s fingerprints and social security number are sent to both the state and the FBI. So any criminal record will be determined well in advance of anyone gaining access to your computers or data.

The real advantage for you is consumer protection. The Texas Private Security Board monitors the licensed investigators and will initiate action if an investigator violates the law, or if a complaint is filed against them.

So, is your Pentester licensed?

Computer Security for Automobiles… We Need It!

Like everything else, our cars are becoming computer controlled. And, like everything with computers inside; people are hacking them so they do different things than they were expected to.

Recently, researchers from Rutgers University and University of South Carolina discovered that the wireless communications between cars and their tires can be captured, intercepted and even forged at distances of up to 40 meters. So, here you are, driving along, late at night, the dashboard lights up and all 4 tires suddenly show ‘low.’ You pull over to see if you ran over a box of nails or something like that. But, when you stop, a guy with a little black box is waiting for you.

Sound crazy? Maybe… But it can happen… Tonight.

In the slightly less SciFi movie category, someone with the right skills, can over ride your car’s remote, turn off the alarm, unlock your car, and be gone in no time. Today. In fact, we pay extra for all but the ‘gone in no time’ part. There are services that will allow a remote agent to turn off the alarm and unlock your car if you lose your keys or leave them inside. The problem is that others may be able to as well.

While there are standards and requirements for the security of systems that handle personal information like your social security and credit card numbers, there aren’t any standards like this for the electronics and computers in your car.

There are other, not so obvious, things to consider as well. Security standards generally require that systems perform self-tests for integrity and function before they are permitted to operate. For systems like anti-lock breaking and air-bag deployment, this is important.

Even if the manufacturers already do self-tests, part of the security standards process is independent examination and testing of the system to ensure that it works correctly, or can determine that it won’t and then alert the operator. This independent testing would add to the reliability and safety of any car. Most of the materials

Cars are no longer the relatively simple mechanical things they were; they now have more computing power than the first spacecraft that went to the moon. We commit ourselves to them every time we get in and go somewhere. But now we aren’t only committing our safety from a mechanical sense, we are also committing our safety from a security perspective. There are good mechanisms already in place in several standards (FIPS 140-2 and Common Criteria for a start) that can take into account security concerns like hacking as well as integrity and reliability concerns. It’s an option we should all consider along with ABS and the killer sound system.


Steve Weingart

Payment Card Industry Compliance for Large Computing Systems: Applying PCI Compliance Standards to Mainframe Environments

Attendees at RSA and Share conferences in March may be interested in a new report from atsec targeted at those working with PCI compliance in Large Computer System environments.

"Payment Card Industry Compliance for Large Computing Systems: Applying PCI Compliance Standards to Mainframe Environments."

Abstract:
Payment Card Industry Compliance for Large Computing Systems, by atsec in association with IBM and other leading Large Computing Systems (LCS) experts, is a report aimed at addressing the need for guidance and information by Qualified Security Assessors (QSA), merchants, and service providers whose card holder data environment is largely based on LCS technology. It may also be of interest to acquirers and card brands demanding compliance with the standards.
Achieving and assessing Payment Card Industry (PCI) compliance in a LCS environment is a challenge as the standards are more focused towards a distributed systems paradigm. A full understanding of the security features and advantages of the complex environment can provide assurance of conformance to the standard but is a very broad and detailed topic.

Drawing from an extensive knowledge of mainframe and LCS security coupled with experience as an accredited QSA company, atsec’s consultants have gained a thorough understanding of the security of these systems at every level, including operating systems, virtualization technology, applications, networking and communication, and mainframe environments. This experience has been gained through Common Criteria evaluation for the US and Europe governments, cryptographic testing and analysis, and mainframe penetration testing for large financial customers on the following systems and applications:

• z/OS
• z/VM
• PR/SM
• System SSL
• DB2
• Oracle
• Multiple Tivoli and third party vendor applications

atsec presents an analysis of the PCI standards in the context of a LCS environment and provides focused guidance to QSA and their customers on the PCI assessment of such environments and the resources available to support an assessment. Drawing from an extensive knowledge of mainframe and LCS security, coupled with experience as an accredited QSA company, this report provides the necessary insight into LCS security to QSA and other PCI professionals.