PCI Security Policies and You - Part 1

[This blog post deals with an article I wrote for the third quarter 2009 issue of Secure Payments Magazine. I have adapted it here particularly for Higher Education. --Walt]

Imagine this situation:

You have been told to create your school’s security policies. You research all the components and compile the requirements for notification in your state, but you have not yet written the policies. OMG! How do I get started?

There is something about security policies – drafting them, reviewing them, following them – that causes otherwise calm professionals to behave badly, or at least irrationally. Responsibility for drafting a policy can get passed through the organization faster than swine flu. Then once they are drafted, suddenly everyone’s too busy to review them. (On a personal note, this is one part where I disagree with the Council's otherwise excellent Prioritized Approach - it holds policy development until the end.)

Possibly this behavior results from our associating “policy” with “control.” Policies are perceived as restrictive, difficult to follow, and an attempt to control behavior. Policies affect everyone in the organization, so they are by their nature political.

I am not going to debate the wisdom of having a comprehensive set of security policies. That conversation is over: PCI DSS compliance requires it. Instead, in this post and the ones that follow I want to focus on what you need to do to help your school develop security policies to meet the requirements of PCI and reflect your institution’s needs effectively and efficiently.

Let's start by looking at what actually are all the PCI Policy Requirements.

Searching PCI DSS version 1.2 yields more than 65 references to the word “policy.” Some references like Requirement 3.1 are straightforward: "Develop a data retention and disposal policy." But other references are broader. For example, 12.1 and 12.1.1 form a catchall requirement to have a security policy that “addresses all PCI requirements.” I put a table together that lists each PCI DSS requirement referencing a written policy. This table becomes your guide for complying with 12.1.

PCI DSS v1.2 Requirement and Corresponding Policy Objective

3.1 Document retention and destruction
3.3 Masking PANs
4.2 Sending unencrypted PANs
5.2 Anti-virus updating
6.1 Security patching
6.3.7 (a and b) Reviewing custom application code changes
7.1 Restricting access to Cardholder Data
8.5.1 User IDs
8.5.7 User passwords
8.5.8 Shared passwords
9.7 Distributing media containing Cardholder Data
9.9 Storing media containing Cardholder Data
9.10 Destroying media containing Cardholder Data
10.6 Reviewing security logs
10.7 Retaining security logs
11.2 Quarterly vulnerability scans
12.1 Policies for all PCI Requirements
12.3 Employee-facing technologies
12.4 Security responsibilities for employees and contractors
12.5 Security management responsibilities
12.6.2 Employee acknowledgement
12.8 (12.8.3) Managing service providers
12.9 Incident response plan
12.9.3 24/7 incident response
12.9.4 Incident response training
12.9.6 Modifying incident response plan

Some of the policies doubtlessly already exist in your organization, and others can be just a few sentences long. Nevertheless, PCI compliance requires a lot of policies. We will look at how your policy writing task may depend on your SAQ in the next installment.

In the meantime, let me know your thoughts. If you have already done this for your institution, I’d love to talk to you about presenting at the Institute’s PCI Workshop in May (and yes, registration is now open!).