December 5, 2010

A Framework for Introducing PCI DSS Requirements

—A look at introducing PCI DSS requirements into a workflow.

In Adventures in PCI DSS Compliance, I noted that the relationships between policies, processes, procedures and configuration standards need to be managed to create a meaningful set of documentation. Approaching compliance from this perspective creates a framework that is both consistent and easily explained to stakeholders.

The framework above is by no means complete but that doesn’t diminish its value. For example, the testing procedure for Requirement 1.1.6 includes a review of the documentation showing that firewall rulesets are reviewed at least every six months.

Since the framework includes configuration standards for firewalls and processes to mange the testing, approval and review of changes to firewalls it is natural ask if any of these can be extended to include firewall ruleset reviews.

There are compelling reasons for including a review of the firewall ruleset while configuring production firewalls.

Rulesets are an output created by the activity of configuring the firewall.
The individual configuring the firewall is in the best position to capture the updated ruleset.
The timing is optimal because configuration errors can be identified when they are introduced.

Using this reasoning, the review appears to fit well in the workflow of an individual configuring a firewall. If this approach is used to introduced the review into the process for changing a firewall then it partially satisfies Requirement 1.1.6. What remains to address is the frequency of this review.

If the firewall is updated at least every six months then nothing is needed beyond ensuring that the date of each review is recorded. If it is not, then scheduling regular reviews is needed. The same individual could be required to include a recurring event in a calendar.

If there are compelling reasons that prevent reviews from occurring when changing a firewall, the framework is still valuable. For example, if the approach described above is feasible but there is a preference for different people to configure and review the ruleset then the review and approvals processes would introduce a workflow that involves another individual.

Even this simple framework helped identify the smallest workflow change that meets the requirement and provided a basis for analyzing the change in light of organizational preferences. Still not convinced?

Imagine trying to introduce this requirement to an already overworked IT team. They aren’t going to be happy about taking on additional tasks. Present them with the requirement and a framework that introduces the smallest possible change to existing workflows and they may be more receptive. Furthermore, objections to the change can be dealt with in a rationale manner that is consistent with the framework and the organization’s way of working.