If you must store credit card data or you are interested in strengthening your current security practices, it is important to focus attention on your Web applications. PCI Requirement 6.6 requires that you 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.
Since the initial requirement was posted by the PCI Security Standards Council, additional clarification was released on April 4, 2008 via an Information Supplement titled, “Requirement 6.6 Code Reviews and Application Firewalls Clarified”. The supplement clarified what constituted a code review. Instead of a straightforward source code review being the only option, automated source code review along with automated and manual Web vulnerability assessment tools will also fulfill the requirement. The supplement also clarified the definition of a Web application firewall and requires that simply plugging in the Web application firewall is not sufficient; it also has to be properly configured.
In order to truly understand which of the options detailed below is the best fit for your company you need to fully understand the strengths and weaknesses of each.
- Code reviews mean that someone or something looks through your source code searching for vulnerabilities. Services like this can be expensive, but can identify both security vulnerabilities in your code and poor coding practices.
- Web vulnerability assessments take the perspective of an outside attacker trying to pull data from your system. They are often faster than a typical code review since the only areas of the site they are checking are externally facing. All of the backend code that may pull down pricelists from the Web, retrieve stock quotes, update figures, etc. will likely not be seen during this assessment. This allows for a narrow focus on what is vulnerable and tests what is most likely to be attacked.
- Web application firewalls are very different from the standard firewall that most people are familiar with, but the concept is very similar. They can take either a blacklist approach (i.e. if a packet/request follows a specific pattern then the firewall denies it) or a whitelist approach (i.e. only allows for specific ports) or a combination. The main difference between a Web application firewall and a standard firewall is what level of the data that they interact with. Traditional firewalls work at the network/transport layer (and some look into the application layer, but is unlikely to satisfy the PCI DSS requirement) whereas Web application firewalls focus solely on the application layer and any method that could be used to attack the Web application. Web application firewalls often act as a second line of defense, situated behind the traditional firewall, they block attacks directed at the Web application.
None of the solutions are bullet proof and will stop everything. Code reviews and vulnerability assessments represent a snapshot in time that assesses your vulnerability level at that moment and may miss some vulnerabilities. If changes are made, additional assessments are required. Your company is to required to address any vulnerabilities found within the code in order to be secure.
Web application firewalls often don’t follow business logic or access control violations and can sometimes be bypassed by a sophisticated attacker who can get around the filter. As most security companies will tell you, (not just because they want to sell you more) a layered approach is better. That means that in a perfect world you would use both an application firewall and some form of code review option.
If all you are interested in is checking off the box on your PCI SAQ, then simply pick a solution, implement it and you are done. If you are interested in using PCI to leverage a more secure system then the solution is to try and get as much defense as you can by supplementing areas where you are strong (but that do not satisfy compliance) with areas that you are weak.
How do you know which approach to take to secure your Web Application?
- Determine where your company is most vulnerable and focus efforts there first.
- Ask your developer if they are aware of cross site scripting, SQL injection and access control violations. If they understand this terminology, ask them if they code to prevent these types of attacks. If they respond positively, then a code review/vulnerability assessment will point out places where your developer cut corners and may be the most efficient tactic for your business. Deploying an application firewall is a good complement to what you already have in place. It adds another layer of protection in case application vulnerabilities that you are unaware of exist in your code.
- If your developers give you a blank stare when you ask them about application attacks or can’t answer how they are protecting the application, then a code review/vulnerability assessment may be the best option for you. A code review will identify areas where the code wasn’t written securely and will hopefully shed light on what your developers are doing wrong and how they can improve. Once you obtain this information you can then turn it into policy/coding standards as guidelines for your existing or future development resources to ensure more secure coding moving forward.
In a perfect world we recommend that you implement both a code review/vulnerability assessment and an application firewall, however your budget may not allow for that. Talk to your staff or development resources to assess their security proficiency and determine the approach that complements practices that you already have in place or that establish the building blocks for a more secure application in the near future.