By Tim Cranny
Panoptic Security Inc.
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."
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.
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.
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:
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.
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.
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.
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.
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
