GS Logo
The Green Sheet, Inc

Please Log in

Banner Ad
View Archives

View PDF of this issue

Care to Share?


Table of Contents

Lead Story

Uncle Sam's finger in the payment pie: A legislative update

Patti Murphy
The Takoma Group

News

Industry Update

Interchange mandates might help, but not everyone

Holidays a boon for data thieves, too

ETAU now in session

An AmEx Revolution

Features

GS Advisory Board:
The best moves of 2009 - Part I

Research Rundown

Selling Prepaid

Prepaid in brief

Origins of the gift card mall

Walter Paulsen
Payments Industry Consultant

Views

Principles for success in 2010

Biff Matthews
CardWare International

Automate or flounder

Scott Henry
VeriFone

Education

Street SmartsSM:
To train or not to train

Jon Perry and Vanessa Lang
888QuikRate.com

Digging into PCI - Parts 5 and 6:
Maintain a vulnerability management program

Tim Cranny
Panoptic Security Inc.

The annual marketing and communications plan

Peggy Bekavac Olson
Strategic Marketing

PIN entry devices: Plan now for July 2010

Joan Herbig
ControlScan

Creating positive consequences:
Three tips

Jeff Fortney
Clearent LLC

Company Profile

Performance Training Systems Bankcard Boot Camp

New Products

Digitizing Cash

CashLINK
Garda

Name recognition for ISOs

CarpéCharge terminal branding
CarpéCharge

Inspiration

Work that family mojo

Departments

10 Years ago in
The Green Sheet

Forum

Resource Guide

Datebook

Skyscraper Ad

The Green Sheet Online Edition

December 14, 2009  •  Issue 09:12:01

previous next

Digging into PCI - Parts 5 and 6:
Maintain a vulnerability management program

By Tim Cranny

This installment of a multipart series addresses the fifth and sixth of 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). I will discuss what the issues are, what merchants need to do, and what their ISOs, banks or processors can do to help.

The fifth PCI requirement is "Use and regularly update anti-virus software or programs"; the sixth is "Develop and maintain secure systems and applications." Together, the two comprise the PCI DSS section titled "Maintain a Vulnerability Management Program." This section deals with some of the primary problem areas for merchants. There are two main reasons why so many issues emerge here:

The purpose of Requirements 5 and 6

The focus of these two requirements is the fact that security issues are not static: the threats are constantly evolving and changing, and that means security solutions need to be constantly updated, improved and fine-tuned.

In most cases this doesn't require much security expertise (most modern solutions will automatically handle the messy details), but compliance does necessitate a certain amount of steady diligence to make sure all the right things are being done.

There is one major exception to the comment I just made about not needing much security expertise: Requirement 6 also deals with cases in which merchants develop their own software. Merchants in that situation absolutely are responsible for a number of highly technical security issues.

It would be a serious mistake to think that, because these two requirements deal with fairly simple, obvious issues, they are not as urgent or important as some other parts of PCI compliance. In fact, many serious security disasters happen every year because of failure to follow these two requirements.

It is sobering to see how often security experts visit the scene of a breach and find that a complete, simple, free solution was available years before disaster struck, but no one bothered to take preventative action by applying the fix. Requirements 5 and 6 are needed to avert such unnecessary disasters.

The challenges of Requirements 5 and 6

For most merchants, Requirements 5 and 6 are about creating and following necessary, routine processes. Most failures here come from a lack of structure or discipline, rather than an inability to deal with some incredibly complicated or obscure technology.

For example, Requirement 5 is the shortest and simplest of the 12 requirements. It only requires that merchants use anti-virus software (which is readily available from many places and comes installed on most computers) and keep it updated (automatic updating is a standard option with anti-virus products and is usually turned on by default).

Requirement 6 is longer and more complicated, but it is still relatively simple. For most merchants it comes down to a few simple issues:

  1. Because new threats and issues are constantly emerging, software needs "maintenance" in almost the same way that a car does. To follow this analogy, you don't need to be a car mechanic, but you do need to arrange to see a mechanic regularly, especially when anything seems to be going wrong.

    For computers the situation is actually more convenient than that: you don't need to take the computer anywhere; you just need to remember to use a few convenient, standard tools to achieve the fixes. The problem comes when merchants forget to follow a process and end up with computers that haven't had any maintenance done on their software for years.

  2. The second issue comes from the fact that computers and computer networks are easy for merchants to modify: every time a merchant adds new software or changes how computers are configured or connected, the business risks creating a major security problem.

Requirement 6 also addresses the need to control changes through processes that establish a "Hey, let's think about this for a minute first and look for unintended consequences before we act" mechanism that kicks in before merchants do something they might later regret.

What merchants need to do

As with Requirement 4 (discussed in the previous installment in this series), the strategy of avoiding challenges rather than defeating them doesn't really work here. Merchants need to focus more on confronting the issues and doing the right thing. This is simply because change of one kind or another is inevitable and unavoidable, and so must be managed.

To meet the demands of Requirement 5, merchants should make sure all their computers have anti-virus software running on them, as well as make sure the automatic-update feature is turned on. In most cases, computers will have this software already installed (even if it is only a 60-day trial version), and activating it is simply a matter of turning it on or agreeing to buy a subscription.

Alternatively, googling "anti-virus" will come up with a dozen different solutions that you can order and install without leaving your chair (some of which are both good and free).

Requirement 6 is more about process, so it can't be purchased, installed and updated in the same way. Merchants need to do things rather than buy things, but what they must do is relatively simple. For most merchants it comes down to a few easy-to-understand issues:

  1. For typical computers, turn on updates - "Windows Update" for Windows operating systems and "Software Update" on Macs. This ensures that operating systems are updated automatically.

    For special devices such as POS terminals, check with your supplier as to whether updates are already being done for you. (There is a good chance they are, but disaster often comes when people make erroneous assumptions about who is handling updates). If updates aren't being done automatically, the vendor will tell you how to set that function up.

    If the vendor can't do that, it's almost certain that the software in question is not in compliance with the Payment Application DSS, and you should start thinking about finding a new vendor.

  2. Pay particular attention to protecting and frequently updating systems that are most likely to be attacked, particularly Web sites and Web applications. These need to be protected by application firewalls or constantly scanned for vulnerabilities, or both. This sort of scanning needs to be a regular event; you might be in good shape today, but that doesn't mean that you'll be safe in a few months.

  3. Establish a formal change-control process. It should describe who in the company is responsible for the cardholder data environment: who approves changes before they are made, how changes are documented, how they are tested before rollout and how they will be reversed if they go wrong. Make sure the process is followed; don't let it become a mere document on a shelf collecting dust.

    One key rule that simplifies Requirement 6: Do not develop software that touches cardholder data in any way unless that is your core business and you are willing to take the time and money to do so carefully and professionally. The time for amateurs has passed. Following this rule will enable you to mark some of the toughest and most dangerous parts of Requirement 6 "Not Applicable," which is even better than "Pass."

What to do for your merchants

Again, this part of the PCI DSS does not entail merchants needing to be rescued from technical nightmares. What they might need is assistance in liaising with vendors of payment applications, POS terminals and other devices that must be PCI compliant.

Merchants will also need general advice on how to set up change-control programs. ISOs can do this themselves if they choose, but it might be simpler and better to partner with a security specialist to provide that sort of hand-holding and expert guidance.

Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at tim.cranny@panopticsecurity.com or 801-599-3454.

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

previous next

Spotlight Innovators:

North American Bancard | Harbortouch | USAePay | IRISCRM.COM | Humboldt Merchant Services