A Thing
The Green SheetGreen Sheet

The Green Sheet Online Edition

April 13, 2009 • Issue 09:04:01

PCI versus tricky technology

By Michael Wright
Panoptic Security Inc.

Use of peer-to-peer (P2P) applications like BitTorrent, Kazaa and the various instant messaging (IM) programs is growing explosively, and their impact on security can be explosive as well. ISOs, merchant level salespeople (MLSs) and merchants who think they don't have to worry about the vulnerabilities in P2P applications should sit up and take notice.

Investigators recently found detailed blueprints and electronic schematics of Marine One, the U.S. president's helicopter, on a server in Iran. This incredible security breach cut straight through multiple layers of security experts, defense contractors and government agencies. And it was caused by misuse of P2P applications.

Payment professionals who aren't concerned about this are basically saying that they, and their merchants, have better security than the President of the United States.

How did such sensitive information make its way onto an Iranian server? Someone installed a P2P file-sharing program on a computer that contained the helicopter specifications.

This made it possible for someone to access these sensitive files and transfer them to other computers. It all came down to just one careless person installing a popular P2P program available everywhere.

Another problem for PCI

Many individuals in the payments industry want to use such P2P and IM programs, too. But if the computers they use also process or store credit card information - or are connected to other computers that do - there are serious Payment Card Industry (PCI) Data Security Standard (DSS) consequences, and major security risks. Requirement 1.1.5 of the PCI DSS requires that all "services, protocols, and ports allowed" into the network be justified and documented.

This is an onerous task. It requires a detailed understanding of every application in the system and how they communicate. Keeping up with the proliferation of protocols is difficult enough for a network security professional, but it is impossible for someone without such training.

Several technical reasons exist why P2P applications can be very difficult to control.

  • Hypertext Transfer Protocol (HTTP) tunneling: HTTP is an application-level protocol that has been used on the World Wide Web since 1990. A tunnel is an intermediary program that acts as a blind relay between two connections. Almost every firewall and security solution lets Web traffic flow between computers simply because the Internet is so useful and so much a part of daily life.

    The problem is that P2P applications know this and basically pretend to be Web traffic. This puts companies in a no-win situation. They have only three options:

    1. Work very hard to spot the difference between typical and fake Web traffic
    2. Block both ordinary and fake traffic, thereby stopping everyone in an organization from using the Internet
    3. Allow both typical and fake traffic, which as we've already seen, causes big security headaches
  • Application level encryption: Many P2P applications can "punch holes" through firewalls and other security solutions by encrypting the data being communicated.

    Encryption turns the data into gibberish that can only be understood by the application at the other end of the conversation. So firewalls and so forth only see the gibberish and have trouble deciding whether to block it.

    To make things more complicated, encryption is not always a danger sign. There are times when encryption is used by the "good guys" for good reasons. For example, Voice over Internet Protocol (VoIP) applications let people make super-cheap phone calls over the Internet, but these applications have to worry about eavesdropping.

    Since anyone with access to a network could listen to a VoIP conversation taking place on the network, many VoIP applications encrypt their messages to stop eavesdropping. This is why many attackers are using VoIP applications to spread malware.

What to do

Given these security vulnerabilities, steps can be taken to minimize risk.

  • Avoid the problem: The easiest way to be compliant with the PCI DSS is, first, if you do not need to process or store the credit card information, then don't. This single step reduces the scope of the PCI requirements for your organization dramatically. If you do store the data, ensure it is protected with encryption.

  • If you can't avoid it, quarantine it: If you must process or store credit card data, then isolate the computers used for this purpose - whether they are POS or regular computers on their own networks.

  • Restrict computer use: Do not allow applications that are not absolutely necessary for processing credit card information to run on computers governed by the PCI DSS.

    This may mean purchasing two computers: one for credit card processing and one for everything else. It may seem like an unnecessary expense, but it is better than having an application surreptitiously transmitting credit card data. The price of a second computer will be a hundred times cheaper than the cost of a data breach.

Further steps

To deal with the danger of P2P applications, ISOs, MLSs, banks, processors and merchants should remember the following:

  • PCI is only part of being secure: Even if you are fully compliant with the PCI DSS, but are running file sharing or other real-time communications application such as IM, there are security issues that you must not ignore. Simply removing these applications does not mean you are secure.

    Think about the information you have on your computer: customer data, product pricing, business plans and so forth. This could easily be exposed by the misuse of any one of these applications. Therefore it is necessary to understand the applications you run in your network and what problems they may cause.

    Also, many folks are sharing copyrighted data such as music files using file-sharing programs. If such files are found on your network and the copyright has been violated by illegal copying, you can be held liable even though you were not aware that such activities were occurring on your network.

  • Avoid PCI problems wherever possible: The best way to deal with security problems is to avoid them. Merchants who make sure they don't store cardholder data on any of their computer systems are much safer than merchants who do. Merchants who don't store data find attaining PCI compliance a much simpler and easier process.

  • Monitor your network: Establish a process that periodically analyzes your network to ensure only authorized protocols are used on your network.

    Control what applications are installed on all computers in your network and restrict user access to only what they need to do their work. Not everyone requires, or should have, administrative privileges on their computers.

    If you must use real-time or file-sharing protocols, do not use them on computers that would be affected by PCI DSS - meaning computers that process or store credit card information. Isolate PCI computers.

  • Be vigilant: Unfortunately, it is an ongoing battle to keep up with the latest applications and their security ramifications. Applications such as IM and file sharing can be beneficial, but they also have security issues that we all must understand; we must apply the appropriate technologies and processes to control them. end of article

    Michael Wright, an internationally recognized security and technology expert, is Chief Technology Officer and founder of Panoptic Security Inc. (www.panopticsecurity.com), which specializes in providing PCI expertise and assistance to ISOs, banks and all their merchants. He can be contacted at michael.wright@panopticsecurity.com.

    The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.

    Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

    Prev Next
A Thing