GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?


Table of Contents

Lead Story

Creating a place for checks at the electronic payments table

Patti Murphy
The Takoma Group

News

Industry Update

ATM ISOs threatened by MasterCard's new fee structure

Visa rattles payments with CyberSource acquisition

ETA honors top leaders

Selling Prepaid

Prepaid in brief

Government streamlines payments with plastic

Prepaid and next-gen payments

Views

The next generation of the check

Ed McLaughlin
RemoteDepositCapture.com

Education

Street SmartsSM:
Referral strategies: What really works?

Ken Musante
Eureka Payments LLC

Two steps toward plentiful referrals

Jeff Fortney
Clearent LLC

Digging into PCI - Part 11:
Regularly test security systems and processes

Tim Cranny
Panoptic Security Inc.

The professional MLS protocol

Jeffrey Shavitz
Charge Card Systems Inc.

Sales and marketing: Allies, not foes

Peggy Bekavac Olson
Strategic Marketing

Company Profile

First Data Corp.

New Products

Radically agnostic

ROAMpay
Company: ROAM Data Inc.

Inspiration

Get on track with a business mentor

Departments

Forum

Resource Guide

Datebook

A Bigger Thing

The Green Sheet Online Edition

May 10, 2010  •  Issue 10:05:01

previous next

Digging into PCI - Part 11:
Regularly test security systems and processes

By Tim Cranny

In this installment of our multipart series, I will drill down on the eleventh of the 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 ISO, bank or processor can do to help them.

Requirement 11 is "Regularly test security systems and processes" and is the second half of the section "Regularly Monitor and Test Networks."

What Requirement 11 is all about

The idea behind Requirement 11 is pre-emptive testing: regular probing of your own card-processing environment as if you were a hacker looking for security flaws in your network setup, your computer programs and anything else that could possibly be attacked. The bottom line is that if you have a security weakness, someone is going to find it: better that it be you than a real attacker.

Just like the issues discussed in Requirement 10, this testing needs to be an active, ongoing process: you cannot simply address it once and then forget it. Instead, you have to keep coming back to it regularly - the more often the better. PCI sets minimums on how often you need to do certain things: some types of testing must be done at least every quarter; other tests need to be performed at least annually. This section of PCI interprets "security systems and processes" in a narrow, computer-centric way, which makes the section only officially relevant to those with computer systems. But, in reality, all security solutions should be regularly tested, even those pertaining to physical security, training, processes and so on.

The challenges of Requirement 11

Even though it is short, Requirement 11 can be extraordinarily difficult for merchants to comply with. Some of the requirements are a bit like saying "Run a marathon each month." This requirement packs a lot of pain into a few words. That is not to say that Requirement 10 is wrong. Just as with Requirement 10, the solutions called for have real value and can do much to prevent real disasters. Like most serious security issues, the cost of a missing solution can be thousands of times higher than the price of purchasing and implementing a preventive solution.

As with Requirement 10, the main challenge of Requirement 11 is that it requires both continual effort and software solutions: a nasty combination.

What merchants need to do

While it is always true that merchants should earnestly endeavor to avoid or minimize the challenges of PCI rather than simply try to defeat them, that can be hard to do with Requirement 11. Avoiding the problems can be too painful in terms of business disruption for that approach to work.

Merchants need to do the following:

  1. If merchants have computers connected to the Internet, each quarter they must get a certified company to do an external vulnerability scan of their computers and network. This is the information technology equivalent of getting a security guard to "rattle the doorknobs" while walking around the outside of a building.

    These scans are a big deal in PCI and are a highly visible part of the process. Merchants must use one of the companies certified by the PCI Security Standards Council (PCI SSC) as an Approved Scanning Vendor (ASV). For almost all merchants, these scans are really the only time their choice of vendor is restricted by the council. A current list of ASVs can be found at www.pcisecuritystandards.org/pdfs/asv_report.html.

    Merchants also need to do these scans after they make significant changes to their card processing environments. This is because test results immediately become "stale" after you change the system that requires testing.

    Merchants need to do the internal version of these scans each quarter as well. This sort of test is a useful complement to the external scan, because doing it from inside reveals different parts of the merchant's world, and can bring tolight different problems.

  2. At least annually, merchants need to do a more intense and active test of their security. This "penetration test" consists of actively trying to exploit any weaknesses or gaps in security, not just identifying them. (Instead of just rattling doorknobs as in a vulnerability scan, those involved in testing should try to open the door, go through it and see how far they can get.)

    Obviously, the test should not involve doing any damage, but it does involve actual testing of network setup, applications and anything else that forms part of the card processing environment.

    As with the vulnerability scans, this should be done both from outside (trying to get in, just like a real attacker would) and from the inside (seeing what attackers would be able to do if they were to get past the outer layer of defense).

    Unlike vulnerability scans, these penetration tests do not have to be done by a certified party approved by the PCI SSC. They can even be done in-house (but ideally done by someone who knows what he or she is doing, and preferably not the same person who set up the systems being tested).

    These penetration tests are a genuinely good idea but can be expensive and confusing for merchants, particularly for small-business owners. They should keep in mind that the PCI SSC states, "The penetration test should be appropriate for the complexity and size of an organization," so there is no need to go overboard on complexity and cost.

    It is better to do something small and simple than never get around to doing something extensive and expensive.

    Because these issues are complicated and confusing, the PCI SSC has written an explanatory document, which is available at www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf.

  3. Each quarter, merchants should do a scan for unauthorized wireless usage on their networks. This is important even for those who do not use wireless because an attacker or a careless employee could add wireless functionality to a network by adding a cheap access point. This can be a serious security problem, especially since wireless access points are now so inexpensive and easy to set up.

  4. Merchants also need to use Intrusion Detection Systems that employ "always on" software (the computer and network equivalent of a burglar alarm) or the more modern and more active Intrusion Prevention Systems (which are more akin to a burglar alarm combined with doors that all slam shut when the alarm goes off).

    Additionally, this software, or other software, also needs to detect when critical computer files are tampered with because that sort of tampering is a big indicator of an attack underway.

    What you need to do for your merchants

    Requirement 11 is one of the very hardest parts of PCI for most merchants, so even a little assistance will be appreciated. The first step, as always, is to give merchants advice to minimize, as far as possible, the number and types of devices subject to PCI compliance.

    Any device or computer that is not clearly involved in dealing with cardholder data should be kept permanently and strictly separated from devices that do need to touch cardholder data. Doing this doesn't make Requirement 11 inapplicable to a given merchant environment, but it does directly reduce the cost and effort involved in compliance.

    For the official vulnerability scans, ISOs and other portfolio owners can provide a clean, simple and low-effort answer by partnering with a specialist security company that provides this service directly to merchants. ISOs that leave their merchants to hunt down their own solution providers are missing an easy opportunity to help their merchants (and preemptively avoid costly support calls).

    For the other parts of this requirement, ISOs should look for a solution package (either in-house or via partnership) that provides merchants with a customized remediation plan (preferably one that also gives ISOs detailed PCI insights and management tools).

    Without these tools, parts of PCI like Requirement 11 can quickly become a portfolio management and support nightmare. But ISOs who focus on building the right partnerships and providing the right services can find that PCI becomes an opportunity for competitive differentiation and portfolio relationship-building.

    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 | USAePay | Impact Paysystems | Electronic Merchant Systems | Board Studios