PCI DSS 6.6 - Getting on the comment bandwagon……
This one’s had quite a bit of press time, and discussion around the blogs recently - moreso as the deadline has approached. In Australia, it’s been relatively quiet in comparison to the US though. I think the fact that compliance across the board here is a way behind the US has a lot to do with that, with many organisations here still either unaware of their responsibilities or far off from being compliant.
Is all the publicity and debate around PCI DSS requirement 6.6 a bit of a storm in a teacup? I think so. I’ll put the case forward also that if your are compliant with the PCI DSS now, the new requirement 6.6 is superfluous:
From the PCI DSS:
6.6 Ensure that all web-facing applications are protected against known attacks by applying either of
the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
(Note: This method is considered a best practice until June 30, 2008, after which it becomes a
requirement).
Okay, taken on face value, it does seem like a big addition to the PCI DSS - code review and/or WAF requirement. But, if you review the requirement against the “intent” so to speak (and that is key to understanding this), and marry that up to the information in “Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified” (Feb 2008), in my opinion, really not much has changed.
PCI DSS Requirement 6 already talks about secure coding practices, review and testing. Requirement 6.5 is reasonably clear on this. PCI DSS Requirement 11 covers web application penetration testing which you would expect would test for application vulnerabilities, as discussed in 6.6. (I don’t know too many web application penetration tests that don’t look for web application vulnerabilities). Given this has to be done yearly or when the environment changes significantly, and based upon intent and what is allowed under “Application Code Reviews” as defined in requirement 6.6, if you’re compliant now, you’re covering the intent of 6.6 already. So the first part of requirement 6.6 is superfluous.
Now given PCI DSS requirement 11.3 has not gone away, and as a compliant organisation, you are doing it, there is no reason for installation of a WAF from a compliance perspective! Sure, add one if you want to the rest of your security suite, but think about it clearly if your reasons are compliance only. I don’t see the need. So all this debate about WAFs in the context of the PCI DSS……waste of time?
Keen on your thoughts.
June 29th, 2008 at 11:12 pm
I came upon this post on Google. This is the most sane and realistic explanation of this requirement I have read. I cannot believe that something so simple and clear has been so blown out of all proportions. Thank you. I will link this to all my clients. I thought I was alone in this thinking.
July 8th, 2008 at 5:54 pm
I find this POV to be disappointing as it appears to be encouraging check box compliance, rather than implementing best practice. A WAF offers significant benefits over and above what a code review requires but if you worked for a code review organization I can see why you would guide clients away from a WAF and therefore towards a nice stream of revenue each time a code review is required.
The reality is that a WAF should form part of a complete code release and deployment methodology and when done so protects an organisation from both known and unknown exploits through protocol sanitisation, signature based attacks, flow controls and a positive security model. A WAF does not leave an organisation at a state which is only as good as the last code review.
Application penetration testing does not provide anywhere near the same level of protection as a good quality, properly integrated WAF.
While saying that a WAF is not a requirement under 6.6 may be correct from a compliance perspective this is a short sighted point of view that provides little resilience to the security posture of an organization and as a result does little to improve the organizations long term security standards.
July 8th, 2008 at 7:47 pm
Hey Wal, I am assuming you’re pulling my leg here.
Per chance you’re not, the theme of the post was on the validation requirements of 6.6. Reading it from the standard seems to be pretty clear, but with the “clarification” document (see link below), it is watered down to the extent where the new requirement in my view is superfluous…thus the post. (Regardless of what I think is good or not).
https://www.pcisecuritystandards.org/tech/supporting_documents.htm
As such, organisations will go down the path of least resistance.
If you are insinuating we’re looking for more code review work, it ain’t going to happen with PCI DSS 6.6 with the watered down standard. It doesn’t happen much now because of the cost to companies. And, we don’t sell WAFs. So it’s a neutral position for us.
Re: your thoughts on WAFs, there’s a recent post here where we talk about this. But, if it’s working for you, that is good.
DD
July 9th, 2008 at 6:49 pm
DD I can assure you that a code review is the easier of the two. As I mentioned in my first post a properly implemented WAF should form part of a complete code release and deployment methodology. Deploying otherwise is a little like configuring your firewall to permit any any. I think it might be time for you to refresh your knowledge of both the f5 and Citrix WAF products, they have changed significantly in the last 12 mths but I will expand on that in the other post.
July 11th, 2008 at 7:49 am
Hey Wal, As I said, if it works for you and your organisation, all good. Re: the code review being the easier of the two - depends on size and complexity of the code I suppose.
My concern is that adding layers of security and allowing that to get in the way of neglecting the basics is not helping anyone. Anything deployed needs to be well thought out and deployed in the context of the environment its supposed to be protecting. We’re probably not too far off each others wavelength.
Am looking forward to reading more in the other post then from you.
DD
July 12th, 2008 at 4:52 pm
A WAF is about admitting that even the best developers make mistakes. Life is full of trade offs and the commerical reality is that sometimes an organisational unit which is not the security department are going to win. Not to pick on anyone vendor especially but what do you do when the off the shelf package you have made a few million for fails the pen test? Oh wait, just this year there were a couple of Australian organisations who did (had to do) exactly that.
If you are going to take the anti WAF view you might as well take an anti firewall, anti anti virus, and an anti anti spam view, after all, all code should be secure by design right? Well while it would be nice to stop the world and all further software releases until Jericho Forum can come up with the goods on that one but I have not yet met a CEO or board that will sign off on that one. So I still hold the line that a WAF is a good idea for any organisation, just like a firewall 5 years ago was a good idea (but now has more service delivery holes in it than a good swiss cheese).
I could understand not wanting to add another layer if the layer didn’t really do anything but a (good) WAF would comfortably cover off the most common attacks.
July 17th, 2008 at 11:01 pm
@Wal, no disrespect but, you have some learning to do. You must be a sales manager for f5 or some other WAF company to have such a strong position on this. Your position goes so against the grain. You make sense on the face of it but you don’t come across as someone who has been in the industry for a long time and knows the battles to what makes for a good infosec strategy. One small step forward can mean 20 steps back in a situation like this. You see the former but easily disregard the latter.
July 17th, 2008 at 11:30 pm
BTW. More here Wal;
http://beastorbuddha.com/2008/07/05/everyone-is-one-the-waf-bandwagon-fk-mewtf/