By Michael Cobb
Enterprises rushing to meet PCI compliance requirements may find themselves in a quandary when it comes to choosing a Web application firewall (WAF). How do you know what to look for? How do you deploy and manage the appliance or software effectively? How do you fit it into your existing infrastructure? We'll highlight the key considerations when evaluating products so your company is in compliance. .
A Web application firewall or application-layer firewall is an appliance or software designed to protect web applications against attacks and data leakage. It sits between a Web client and a Web server, analyzing application layer messages for violations in the programmed security policy. Web application firewalls address different security issues than network firewalls and intrusion detection/prevention systems, which are designed to defend the perimeter of a network. But before you rush to buy, you'll need to understand that this is not a plug-and-play check box compliance item and requires more than just putting an appliance in front of your application servers.
|Step by Step: Choosing a WAF|
Follow these basic steps in selecting the appropriate Web application firewall for your application:
What you need to know
Whenever new legislation or security requirements are introduced, those tasked with ensuring compliance often tend to rush the decision-making process. Many system administrators base their decision on a single vendor's sales pitch or a particular requirement or feature they've picked up on.
The result, more than likely, will be inappropriate or less than optimal security. Even a tight deadline doesn't absolve you of due diligence. To choose a security device such as a Web application firewall, you need to answer the following questions:
- What does it need to do based on your security policy objectives and legislative requirements?
- What additional services would be valuable?
- How will it fit into your existing network -- do you have the in-house skills to use it correctly and effectively?
- How will it affect existing services and users and at what cost?
New compliance requirements such as PCI DSS require you to update or at least review your security policy before you can answer the first question. A good security policy defines your objectives and requirements for securing your data. That foundation allows you to define what security devices are appropriate to meet your requirements. Since each Web application is unique, security must be custom-tailored to protect against the potential threats identified during the threat modeling phase of your secure lifecycle development program. Review which of these threats the WAFs under consideration safeguard against--such as analyzing parameters passed via cookies or URLs and providing defenses against all of the OWASP Top Ten application vulnerabilities--as well as any additional requirements mandated for compliance.
Choosing your WAF
To ensure a WAF is suitable for PCI DSS compliance purposes you should compare its capabilities with those recommended in the Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified" [Link: https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf] issued by the PCI Security Standards Council.
They must be able to inspect and handle Web page content such as HTML, Dynamic HTML (DHTML), and cascading style sheets (CSS), as well as the protocols that your application uses, such as HTTP and HTTPS.
Also, check how quickly the vendor has adopted new protocols in the past. Review their development and support policy to determine if they will support custom protocols or protect a set range of application protocols. In addition, a WAF must be able to inspect Web services messages, typically SOAP and XML. Ask the WAF vendor about their processes for auto-updating and applying dynamic signatures. Such conversations will help you assess their technical support and help services.
Lastly, ask about the additional cost of specific features. For example, some applications may require FIPS hardware key store support. A WAF vendor may support this requirement but at a dramatically higher price.
As you work through the list of requirements, take the time to understand the technical approaches and depth of treatment that each WAF uses to provide coverage of one or more security areas. Can you white list data types and ranges and create rules combining both white and black lists? How strong is the WAF against attack on itself? For example, it should run on a hardened OS, probably with components running in a non-privileged and closed runtime environment. If the product's security isn't rock solid, you should probably end the discussion right there.
Web application firewalls are just the start.
TO COMBAT the ever-increasing sophistication of application attacks, the protection offered by WAFs should be integrated into application assurance platforms. This structure, promoted by vendors such as F5 and Barracuda, combines WAFs, database security, XML security gateways and application traffic management to provide more holistic security coverage.
The benefits include the ability to compare information across these devices to accurately determine if traffic is potentially malicious. This makes traffic control, analysis and reporting far more effective. Administrators can configure one set of policy rules and parameters, rather than trying to enforce each policy across several different devices, greatly reducing administrative overhead.
Looking into the future, it is essential that WAFs or whatever supercedes them gain the ability to interpret inbound data the same way as the application it is protecting. This will entail some form of script engine to remove any obfuscation, so that the security device will view the request in the same form that the browser will. This will make it far easier to assess whether or not the code is malicious. Let's hope we will see this form of dynamic analysis in the next generation of security devices.
Software vs. Hardware
The PCI Information Supplement states that a WAF can be implemented in software on a standard server running a common operating system or an appliance. It may be a stand-alone device or integrated into other network components. So, you can choose from the full range of WAFs on the market.
Software WAFs are usually cheaper and more flexible. Appliances are typically easier to install and configure, partly because their operating system has already been hardened, whereas a software firewall will require you to harden it. (A WAF won't protect you against poor configurations or vulnerabilities in your servers.)
If you opt for a software-based product, choose one that works on a platform with which your IT department is familiar. Either way, check out what type of training and support is provided by the firewall vendor--and at what cost.
There are, of course, open source software WAFs, such as ModSecurity[http://modsecurity.org] and AQTRONIX WebKnight [http://www.aqtronix.com]. If they meet your requirements you can greatly reduce your costs, but you will still need staff to learn, install, configure, and maintain it. Many open source projects have excellent support forums but unlike a purchased product you won't be able to call a help desk in an emergency.
Performance and scalability are other important considerations when evaluating hardware or software options. Some devices may be limited as to how many transactions per hour it can handle. Other appliances may have bandwidth limitations. You will need to choose a scalable and flexible firewall if you're planning on increased Web activity or adding applications in the near future.
Software products often provide an easier upgrade path than appliances, but hardware WAFs are better suited for high-volume sites, which require high throughput.
If you are running a large-scale application, which requires more than one WAF, then centralized management may be a critical feature so firewall policies can be deployed and managed from a single location.
Our advice is not to get hung up on whether the WAF is hardware or software, as long as it can meets your objectives and you have the in-house skills to configure and manage it.
|Primer: PCI DSS|
What you need to know about PCI DSS
THE PAYMENT CARD INDUSTRY Data Security Standard (PCI DSS) was developed by the PCI Security Standards Council, an open forum launched in 2006. The council is part of PCI, a joint industry organization set up by a group of the major credit card companies, and is responsible for the ongoing development, management, education, and awareness of the PCI DSS.
However, it doesn't enforce the PCI DSS, nor does it set the penalties for any violations. Enforcement is left to the specific credit card companies and acquirers. PCI DSS does not replace individual credit card company's compliance programs but has been incorporated as the technical requirements for data security compliance. The PCI DSS must be met by all merchants that accept credit and debit cards issued by the major credit card companies.
Under the PCI DSS, an organization must be able to assure their customers that their credit card data, account information, and transaction information is safe from hackers or any malicious system intrusion by adopting various specific measures to ensure data security. These include building and maintaining a secure IT network, protecting cardholder data and maintaining a vulnerability management program and information security policy.
The standard's compliance requirements are ranked in four levels, and the level of compliance required of a merchant is based upon the annual volume of payment card transactions it processes. Level 1, the highest level, can also be imposed on organizations that have been attacked or are otherwise deemed as high risk. A single violation of any of the requirements can trigger an overall non-compliant status, resulting in fines, and, possibly, suspension or revocation of card processing privileges until the merchant is PCI compliant.
For more details, visit the PCI Security Standards Council website.
Help is on hand
Plan on devoting plenty of time to fully evaluate WAF products. Once you have narrowed down your choices to those that meet your basic requirements, how do you compare the different options?
The Web Application Security Consortium (WASC) [Link: http://www.webappsec.org/] creates and advocates standards for Web application security. They have developed the Web Application Firewall Evaluation Criteria (WAFEC) [Link: http://www.webappsec.org/projects/wafec/] for comparisons. Their testing methodology can be used by any reasonably skilled technician to independently assess the quality of a WAF solution.
Use their criteria as part of your evaluation process. Follow WASC's recommendation to pay close attention to the deployment architecture used, support for HTTP, HTML and XML, detection and protection techniques employed, logging and reporting capabilities, and management and performance.
Congratulations. You've chosen, purchased and installed a WAF with the necessary compliance capabilities. But that doesn't mean that you're compliant. Proper positioning, configuration, administration and monitoring are essential.
Installation needs to follow the four-step security lifecycle: Secure, monitor, test and improve. This is a continuous process that loops back on itself in a persistent cycle of protection. Before any device is connected to your network, you need to ensure that you have documented the network infrastructure and hardened the device or the box it will run on. This means applying patches as well as taking the time to configure the device for increased security.
Configuration will stem directly from the business rules that you've established in your security policy (such as allowed character sets). If you approach firewall configuration this way, the rules and filters will define themselves. WAFs can expose technical problems within a network or application, such as false positive alerts or traffic bottlenecks.
Careful testing is essential, particularly if your site makes use of unusual headers, URLs or cookies, or specific content that does not conform to Web standards. Extra testing time should be allowed if you are running multi-language versions of your application, as it may have to handle different character sets.
The testing should match the "live" application environment as closely as possible. This will help expose any system integration issues the WAF may cause prior to deployment. Stress testing the WAF using tools with Microsoft's Web Application Stress and Capacity Analysis Tools or AppPerfect Load Tester will also help reveal any bottlenecks caused by the positioning of the WAF.
Once you're up and running, assess how any future Web application firewall changes may impact your Web applications, and vice versa. You must, of course, document the changes you make to your network infrastructure for future reference and troubleshooting. This involves tracking any changes made to their configuration now and in the future.
Changes to the production environment should always occur during a monitored maintenance window. Make sure all affected parties throughout the organization are advised in advance of the timing and scope of the changes. To ensure that configurations aren't changed unintentionally or without due process, you must control physical as well as logical access to your security devices. Strict adherence to change control, business continuity, and disaster recovery policies will all play a part in protecting the WAF and your business.
Because application-layer firewalls examine the entire network packet rather than just the network addresses and ports, they have more extensive logging capabilities and can record application-specific commands. So, don't let this capability and information go to waste. Log file analysis can warn you of impending or current attacks. Ensure that you define what information you want your firewall to log--preferably the full request and response data, including headers and body payloads. Make sure your staff have the expertise--and adequate time--to review and analyze it.
Web applications will never be 100 percent secure. Even without internal pressures to deploy Web applications quickly, there will be vulnerabilities that are open to threats. By having a Web application firewall in place as part of a layered security model, you can observe, monitor and look for signs of intrusion. It can also mean the difference between scrambling to fix a vulnerability or having the breathing room to repair the vulnerability to your own timetable.
Michael Cobb, CISSP-ISSAP, is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. Send comments on this article to firstname.lastname@example.org