Some excellent commentary from Mark Curphey on the subject of the PCI DSS over on his blog at http://securitybuddha.com/.
The other element of the PCI DSS that is of concern is the Audit Procedures and Reporting document designed to be used as the principle guidance for PCI certified auditors. Picking up on Mark’s point about item 1.1.9 and the requirement for configuration standards for routers, the audit guide is just as ambigious in only instructing auditors to “Verify that firewall configuration standards include both firewalls and routers.” That’s it!
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Another audit clause that really gripes me is this one:
6.5.b For any web-based application, inquire (sk – shouldn’t that be enquire?) of a sample of (insert sample size) web developers and obtain evidence that they are knowledgeable in secure coding techniques
How does this clause mitigate risk? It provides no constructive guidance whatever except a vague expectation that some-one is going to know the right set of questions to ask.
It’s almost as vague as the audit guide around clause 6.5.10 which expects the auditor to check there is no “insecure configuration management.” What does that mean? You can have poorly managed configuration management or incorrect configurations resulting from errors and lack of knowledge but I don’t know if that is the same thing as insecure configuration management. Perhaps they are referring to insecurities of the person performing the management. I imagine they are on the lookout for some network admin asking himself “am I any good at this whole configuration lark?”…..
What is boils down to is that the audit guide is just as ambigious as the standard itself.