A Thing
The Green SheetGreen Sheet

The Green Sheet Online Edition

June 14, 2010 • Issue 10:06:01

Digging into PCI - Part 12: Maintain a policy that addresses information security for employees and contractors

By Tim Cranny
Panoptic Security Inc.

Editor's Note: This series began Aug. 10, 2009, in issue 10:08:01 of The Green Sheet. All articles in the series are now archived online. To access them, search for "Digging into PCI" (without the quote marks) using the Fast Finder search engine located just below the GS logo on our home page, www.greensheet.com. A list of all 11 articles (Requirements 5 and 6 were addressed in one article) will appear.

This final installment of a multipart series drills down on the last of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). In this article, I will talk about what the issues are, what merchants need to do, and what their ISO, bank or processor can do to help them.

The idea behind Requirement 12

The idea behind Requirement 12 is simple: security is a continual, often complicated process, and there is no chance of getting it right if implemented in a disorganized, ad-hoc manner. Having clear, formal objectives (policies) and plans on how to get there (procedures) creates success.

Requirement 12 lays out the basic areas that a merchant's security policy should address and makes sure the right general framework of procedures is in place and the right roles and responsibilities are properly assigned.

This framework of policies and procedures provides coherency for all the other requirements. It forms the foundation of everything else because merchants need to know what is expected of them before they sit down to construct their policy framework. It lays out the general high-level objectives (the what), while the other 11 requirements flesh out the details and specifics (the how, where and when).

The challenges of Requirement 12

Requirement 12 is not concerned with the technical details inherent in other parts of PCI. This makes it less scary but also introduces the risk that merchants will think it is too abstract to matter. Ignoring its importance would be a mistake, however. "Wasting time" on policies and procedures is like a hunter "wasting time" aiming the rifle before firing or a carpenter "wasting time" measuring the wood before cutting.

Another challenge with Requirement 12 is its high-level approach, which takes merchants away from the comfort of specificity. The PCI DSS is unusual for a modern security standard in its level of detail; most of the time it removes the need for judgment calls by effectively leaning over the merchant's shoulder and saying, "Do this, then this, then this, and don't do that." This hand-holding goes away to some degree in Requirement 12, and merchants who don't know much about security can easily feel lost.

For this reason, Requirement 12 is one of those dangerous sections that can generate horrific (but often hidden) support costs for ISOs and other portfolio owners if approached with a low-cost, low-feature solution.

What merchants need to do

Unlike many other parts of PCI, you can't avoid Requirement 12, nor does it make much sense to even try. However, complying with Requirement 12 doesn't have to be complicated and time-consuming; merchants with simple and relatively low-risk environments can make their policy and procedure frameworks simple as well.

Merchants need to do the following:

  • Have a written security policy that addresses (at a high level) steps for complying with PCI in your particular environment. Avoid one-size-fits-all templates: they can either leave important information out or include information that is confusing or irrelevant (for example, a one-size-fits-all template may contain information about wireless networking that is useless to a merchant who doesn't use it).

    The policy should not be technology-specific: it is more about what, not how.

  • The policy-and-procedure framework should be all-encompassing, addressing even how you treat your policies and procedures. Review and update the policies and procedures at least annually and distribute and explain them to staff.

  • Put in place a framework of procedures that reinforces those policies and makes them real. Procedures are naturally more detail-oriented than policies, are not necessarily technology-neutral, and should detail specific sequences of steps to be taken, where appropriate.

  • Assign and enforce roles and responsibilities for security issues. It never works to say, "Someone has to make sure that ..." Assign specific tasks to specific individuals, or designate that a task requires no action.

  • Because the world is so interconnected, you can't implement security inside your own company and ignore the rest of the world. Businesses that rely on partners or service providers need to pass their PCI responsibilities on to those partners.

  • Put in place an incident response plan, so that when a security incident happens, no one has to think too much on their feet about what actions to take.

    A crisis is a bad time to start thinking about what your response ought to be. Clear, accessible guidelines should already exist for people to follow.

With all of these issues, merchants should recognize that it is better to actually put together a simple set of policies and procedures than never get around to creating the ultimate, most highly detailed version possible.

What you need to do for merchants

Merchants can't implement Requirement 12 by applying some hardware or software solution; they need expert assistance. ISOs can either provide this assistance directly or partner with someone who can.

The company providing this assistance must have the capability to craft merchant-customized security policies and other content-rich documents and help the merchant decide which parts of the requirement are relevant to the merchant's business.

ISOs that can provide this in-house or through partnership can turn PCI from an expense and inconvenience into a means of securing merchant loyalty.

Stay in touch

I hope you have found the guidance provided in this series to be helpful. If you have questions about the issues I've addressed or suggestions for further areas of PCI compliance you would like me to delve into in the future, please do not hesitate to contact me. end of article

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 or 801-599 3454.

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

Prev Next
A Thing