Sunday, November 28, 2010

Adventures in PCI DSS Compliance

I've been reviewing the Payment Card Industry Data Security Standard (PCI DSS) for purposes of obtaining compliance. The standard includes 12 requirements for any business that stores, processes or transmits payment cardholder data.

One of the first things I looked at was the documentation requirements placed upon an organization. What I found is both interesting and likely a source of confusion for many organizations. 

Here is an example of some documentation requirements in PCI DSS, version 1.2:
Requirement 1.1 Establish firewall and router configuration standards that include the following:
Requirement 1.1.1 A formal process for approving and testing all external network connections and changes to the firewall and router configurations.
An obvious question is what form must these standards and processes take in order to comply with these requirements?

The test procedures provide these hints:
Test Procedure 1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. 
Test Procedure 1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.
The guidance provides these hints:
 Guidance 1.1 Without policies and procedures in place to document how staff should configure firewalls and routers ... The policies and procedures will help to ensure that the organization’s first line of defence in the protection of its data remains strong.
Guidance 1.1.1  A policy and process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network, router, or firewall.
The glossary provides these hints:
Policy: Organization-wide rules governing acceptable use of computing resources, security practices, and guiding development of operational procedures.
Procedure:descriptive narrative for a policy. A procedure is the “how to” for a policy and describes how the policy is to be implemented.
In effect, these requirements introduce the following documents into an organization.

  • Firewall and router configuration standards to ensure the proper configuration of these devices. 
  • A process for approving the testing and changing of firewalls and routers. 
  • A process for testing changes to firewalls and routers. 
  • A process for changing firewalls and routers.

The guidance introduces policies governing these processes and standards.

There is no definition of a process in the standard. The reference to "other documentation" in the testing procedures is a catch-all phrase that implies the existence of documentation for managing the configuration standards and processes. These documents may or may not be the policies referred to in the guidance.

The implications for an organization seeking compliance with PCI DSS is that a hierarchical structure for the following documents is implied.
  • Policies defining the rules governing the acceptable use of computing resources, security practices, development and operational procedures.
  • The processes and procedures that enforce the policies.
  • Standards that ensure the proper configuration of routers and firewalls.
An organization is free to determine which form these documents take. This implies that using existing documentation to address PCI DSS requirements is both feasible and desirable.

The guidance defining policy implies that policies cover a broad range of business activities.  This implies that organizations without policies in place to address these issues should refrain from taking a narrow view PCI DSS compliance. Instead view it as an opportunity to improve governance on these issues. Of course, PCI DSS isn't intended for developing governance. It just provides a red flag for organizations who might be missing some important elements of governance relating to protecting cardholder data.

No comments:

Post a Comment