Neohaxor.org

I have had plenty of interesting conversations with people on this topic. Everyone seems to have a different opinion. There has been quite a bit of discussion around web application firewalls (WAFs) with the PCI DSS 6.6 requirement looming. I am glad that the PCI Standards Counsel has given some clarification around 6.6 as to their intent and compliance. The information can be found here:

Here

I think they rather well explained their position and they have great cause for concern in this area. This particular section of the PCI DSS has now sparked quite a few debates. PCI 6.6 basically states that you ether have to have code review or a web application firewall (WAF). I am sure that WAF vendors are ecstatic. I feel the finding will have people opting for the WAF and figuring they are secure. This is not the case and is a false sense of security. Always remember, when it comes to the protection of your assets it is still your responsibility.

Validating the Code

The clarification document specifies a few different methods for validating the code. Each of the different methods would yield different results based on the individuals doing the assessment. This is easy to find in just about any standard or piece of compliance. I really believe the intent is to find the big vulns and the low hanging fruit. There are still so many applications vulnerable to SQL injection and XSS it isn’t funny. Would the methods described by the PCI clarification find these vulnerabilities? For the most part I think yes. Each method described can have wildly different results but each method should (for the most part) at least alert someone to the existence of these basic vulnerabilities. At the very least it raises awareness.

Now what about this whole other world that lies outside your door? This world that deals in actually trying to secure your applications? Well that is a door that organizations are going to have to choose to walk through on their own. We all know there are plenty of organizations that won’t choose this door.

There is always a difference between complying with standards / compliance and doing what you are supposed to do. Should you just try and comply and take the easiest road possible? Of course not. There are always going to be organizations that do just try and comply. By the time issues make it in a piece of regulatory compliance it is way too late and often too little. Standards and regulatory compliance have to be broad so they can deal with many organizations and try to accomplish the intent for each of the requirements.

One other thing I noticed about the clarification document was the use of the word “qualified”. That is an extremely generic term that is left up to quite a bit of interpretation. Having an individual internal to the organization have the final say on the application assessment is not a good idea in my opinion. I am a big believer in 3rd party validation. A 3rd party, experienced in analyzing web applications, should conduct the assessment (when compliance is involved). This experienced 3rd party should also use a variety of methods to verify that the application exhibits an appropriate level of security.

WAFs?

What about using a WAF instead of analyzing the application? You should never use a device to cover up a vulnerability and call it quits.

“Well we can’t patch our boxes so we might as well just use a firewall”

The previous statement doesn’t make sense. There are two many other variables in play to make this a viable solution for protecting your assets. What is someone misconfigures the device? What if the device fails open? What if the firewall has a vulnerability? The list goes on and on. With web application firewalls it can be far worse. With web applications, most often sensitive data is just a few steps away from any attacker already. The only true way to secure web applications is through proper design, coding, configuration, and maintenance. You should never, ever just cover up a vulnerability that you know about. Plus can you imagine having to explain to people, “Yeah we got owned, but I thought we had the vulnerability covered up”.

Web application firewalls, like network firewalls, are a layered security control. These layered controls are what you use in addition to other controls to protect your assets. Layered controls should never be used as primary controls, unfortunately this is often the case.

Basically the reasons to not just use a WAF are as follows:

1. Misconfigurations could leave you vulnerable.
2. A fail open situation could leave you vulnerable.
3. Depending on configuration wouldn’t protect you from internal personnel and business partner networks.
4. Vulnerabilities run deeper than just SQL Injection, XSS, and other common web flaws. Flaws in business logic and session data are pretty devastating too.
5. Unforeseen vulnerabilities in the WAF product itself.

I just listed a few quick points and there are more. On another note, I have never ran in to a situation where an application had something devastating like a SQL Injection vulnerability and the rest of the application was just fine. There are usually other flaws in logic and authorization as well. These are all items to consider when designing your protection strategy.

What should you do?

Ideally you should implement both the analysis of the application and the WAF. This will afford you the best protection. You will have the knowledge of knowing your application is solid and get the advantages of protection and logging from a WAF. This is assuming you use the right vendors for both but I am not even going to touch on that in this post.

What if there is no access to source code to fix flaws?

If there are vulnerabilities identified and there is not access to source code for whatever reason you should implement the WAF while you work on the fix. If it is a COTS application then you should contact the vendor and have them work on a fix. If it is a custom built application a plan should be put in place to deploy new code that complies with proper coding procedures. Developing new code is definitely a pain, but will serve you much better in the long run and will help ensure that you don’t get owned

You Shouldn’t Stop Here

You shouldn’t just stop here. There are plenty of other variables that affect the security of your assets. The environment, configuration, code management, policies, patches, and many other factors affect the security of your assets as well. Protecting your assets requires a holistic approach with a layered defense. If organizations are serious about securing their assets they will use a holistic approach and not just try to satisfy requirements. I just hope that organizations choose to do the right thing. I won’t hold my breath though, this hasn’t been the road traveled in the past.

I found this quite humorous. While flying back home I was standing in one of the useless “Hey we are doing something about security” lines at the airport. A few people ahead of me was a girl about 13 years old. She put her bag on the belt and as it went through she walked through the metal detector. The belt stopped and the woman running machine called her supervisor over. They ran the bag the rest of the way through. The supervisor then reached in to the girl’s bag and pulled out a 2 liter bottle of Sprite.

The supervisor walked over to the people waiting in line and said, “This is an example of what you can’t bring through”. She then took the bottle and threw it directly in the trash next to the security line. People started to chuckle a little bit then I heard a man say, “I am glad they caught that”. I turned to him and asked if he knew something that I didn’t know. He looked at me like I was crazy. I asked, “Is Sprite the next big threat to air travel?” He replied, “Well it could be something else”. To which I replied, “Well if it is your in trouble because she threw it in the trash can right next to you”.

My point was obviously lost. Everyone knew it was Sprite. It is what it is. At times I get frustrated about the differences between actual and perceived security. I was making a couple of points to the people in line. The most important point was that if it was something hazardous they just chucked it in the trash right next to them. I wish people would demand more from the people supposedly “securing” them. Unfortunately I think there is a perception that it will require more from them as well. I can’t say as I blame the people with the previously stated perception. Security implemented poorly is often a unnecessary drain on many resources.

Alright, well I just couldn’t resist having some fun with the Microsoft Heroes ad campaign. The graphic says it all.