Don't Chase Checkboxes

Drew Conry-Murray takes apart PCI in his recent blog PCI Is Meaningless, But We Still Need It. I agree with most of his points, but they mostly apply to companies that view compliance as a set of checkboxes that have to be filled in annually. Filling checkboxes is doomed to failure. Focus on the spirit of the requirements and your company's security posture will be the better for it.Organizations that try to regulate behavior, whether it's the U.S. Department of Health and Human Services with HIPAA or the PCI Council requirements, are trying to articulate in measurable ways, the features and functions that should be in place to protect personal information. Doing so sounds easy in concept, but in all practicality, developing measurable technical requirements for a broad audience is an extremely difficult task. Requirements need to be specific enough to be addressable by the target audience while being broad enough that you don't have to make modifications on a constant basis.

But if that's all you're looking at in a regulated industry -- am I satisfying this or that line item -- and not the big picture, you are missing the point.

Consider regulations and requirements as a codification of best practices. Picking on PCI 1.2 for the moment, if you read requirement 1 -- "Install and maintain a firewall configuration to protect cardholder data," there's a whole lot of room for interpretation in that section and I can imagine a number of ways that I could configure a firewall to comply with the requirement, yet be "insecure."

However, the responsible action is to look at what requirement No. 1 is driving at, which is to ensure that you have a properly configured firewall in place that only allows the necessary access in and out of sensitive areas and that there is a formal process in place to initiate, review, justify, and test changes of the firewall. Seems like a best practice to me. If you adhere to the spirit of CPI requirement No. 1, then you can't help but comply with the line items. I'd hope that any well-managed IT shop can do that with their eyes closed.

I know there are some really vague requirements, like 6.6, where one option for public-facing Web applications is to use a Web application firewall configured to detect and prevent Web-based attacks. What kind of Web application attacks? Cross-site scripting? Transferring viruses through HTTP downloads? SQL Injection? Unicode attacks? All, none? How would you measure the effectiveness of the Web application firewall? What is the accepted practice and standards? Apparently, a clarification to section 6.6 will be coming soon, but in the meantime, what do you do?

I think you can't go wrong if, like any other best practice, you make every attempt to properly configure, document, and test your Web application firewall for your environment. Make it part of your change control process, the modification and testing of any Web application firewall rules.

You have to pass an annual audit, but you have a responsibility to protect your customer data from loss. Focus on protecting customer data and the rest will follow.