Avoid Common Errors When Configuring Your WAF

The dramatic uptake in Web 2.0 usage has seen a massive increase in sites mixing user generated content, live feeds, interactive content alongside traditional images and text: only 10 years ago, Facebook and Twitter simply wasn’t possible.

But the IT security implications can be daunting: many Web 2.0 sites use mash-ups (many different elements and functionality drawn from multiple sources) so there is no means of validating its code. Additionally, as Web 2.0 sites mature and become more dynamic, it’s more difficult to identify any “normal” traffic patterns which can be used as a yardstick for setting usage policies or firewall rules: as a result, sites are vulnerable to attack.

Web Application Firewalls (WAFs) were developed to counter these threats: unlike the traditional firewall which protects the entire network, a WAF only secures the web servers. Sitting between the web client and web server, WAFs monitor every request and response within the application layers. They look for specific “attack signatures” to identify a specific incoming attack, whilst monitoring for abnormal behaviours that don’t fit with past traffic patterns.

Whilst WAFs are fundamental to the security of any web application, they’re only truly effective if configured properly. Most problems result from their poor initial configuration rather than their operation, but a few simple steps can avoid the most frequently cited problems:

Co-ordinating WAF Configuration with Web Update Cycle This may seem almost too obvious to highlight, but configuring the WAF in parallel with web application's update cycle prevents significant problems. The optimum time to configure a WAF is when the website is being updated or patches are implemented. If the two operations don’t happen at the same time, there’s a strong likelihood that part – or all – of the application will not be protected. In this case, the WAF will identify part of the application as a rogue element and block it. The consequence can be severe for the site’s users, who experience problems such as news feeds dropping out, message posts not uploading and content being inaccessible.

Check Third Party Code for Bugs/Vulnerabilities Mash-ups, feeds and/or aggregators are the essence of Web 2.0, but if they harbour vulnerabilities, they put the whole web infrastructure at risk from attack. Wrapping a WAF in front of a site will protect it, but for 100% peace of mind, a secure application vulnerability check (before you implement it) is the way forward. This kind of assessment gives detailed information about what's going to affect the site - before it happens. There are multiple assessment tools available, some proprietary and some not. Whilst they all scan for vulnerabilities, the most suitable one will probably be determined by its compatibility with the WAF you’ve installed. Assessment tools are available in manual and automated versions: the manual ones are conducted by external organisations or consultants and meet the PCI requirements, whilst automated assessments are handled by external scanning software. For real peace of mind, it’s sensible to run both a manual and automated assessment. It’s also worth feeding back the results of the vulnerability check to vendors: they like to know if/where they need to make changes. It costs nothing and helps everyone avoid the same pitfalls.

Only the one change, manual va's are conducted by outside testers (as in people) automated va's by external scanning software, cost is irrelevant, its apples and oranges. However both should be done

Use a WAF with built in Acceleration IT departments often worry that WAFs mean latency and impact on users’ experience and productivity. If this is an issue, opt for a WAF with inbuilt application acceleration - it mitigates web latency and speeds overall traffic.

Lock the Back Door – As well as the Front! By using WAFs to protect the front door (ie. applications) IT departments often neglect the back door (ie. data security/back end applications) security. If the WAF misses something, then the whole site is vulnerable. Securing both ends can be achieved with a database activity monitoring solution, a WAF and vulnerability assessment at the outset.

It may sound costly and a bit excessive, but an all encompassing option will highlight all the issues which need to be addressed, before they can cause real damage. The costs involved are negligible compared with the financial, operational and reputation costs of a major web incident.

In the US, this “belt and braces” approach to web security is widespread; this may be due to more exposure to website fraud or simply a more stringent compliance requirements. Over the next couple of years, it’s likely that the UK will follow a similar path: in no small part spurred on by news such as the recent Web Hacking Incidents Data Report which showed a sharp rise in web hacking incidents for social networking sites such as Twitter posts. These accounted for 19% of all web hacking incidents from January to July 2009 and this trend looks set to continue for the foreseeable future.

A stark indication that WAFs and wide ranging web security assessments need to move from the IT department’s “Wish List” to being seen as necessities in a Web 2.0 dominated world.

Author: Nick Garlick, Managing Director – Nebulas Solutions Group

October 2009