Web applications remain one of the most vulnerable parts of the enterprise computing infrastructure. Organizations have taken extraordinary measures over the past decade to shore up network security as well as platform and hardware security in the data center, but Web applications have generally been left behind. The complexity of Web applications combined with a lack of security awareness among developers leads to a woeful state of vulnerability to SQL injection and cross-site scripting (XSS), even though these types of attacks have been happening for years. Estimates from application security vendor WhiteHat indicate that it would take the banking industry alone 400 days to patch 90% of the flaws in their applications.
The complexity of Web applications combined with a lack of security awareness among developers leads to a woeful state of vulnerability to SQL injection and cross-site scripting (XSS), even though these types of attacks have been happening for years.
This creates a compliance dilemma. The Payment Card Industry Data Security Standard (PCI DSS), for instance, requires regular application code scans to identify flaws that attackers could exploit. However, the time and work involved in this endeavor is, for most organizations, simply too great. One potential solution to this dilemma is the use of compensating controls to safeguard against existing and future application flaws. Web application firewalls (WAFs) fit this bill, and PCI DSS allows their use in lieu of regular application scans. These devices, like traditional network firewalls, monitor traffic coming into a network, with a specific emphasis on the requests headed to Web servers. They perform deep content inspection on these requests, looking for HTTP commands that violate an organization's security policy and/or include potentially malicious code, such as a SQL injection attack.
In this tip, we'll explore not only the role Web application firewalls can play in securing a Web application infrastructure and meeting compliance demands, but also the secure software development processes that can shore up an organization's application security strategy.
Meeting PCI DSS requirements with WAFs
The most recent revisions to PCI DSS include specific language around Web application firewalls. PCI DSS requirement 6.6 mandates that organizations with public-facing Web applications address emerging threats with at least one of two approaches:
- Performing manual or automated application vulnerability assessments on an annual basis and after any changes;
- Installing a Web application firewall in front of public-facing Web applications.
This is an area where I'd recommend going above and beyond the requirement and implementing both of these security controls. While the standard may only require one, this is too important an area of risk to rely upon a single control.
That said, when it comes to certifying compliance, I'd suggest using the Web application firewall as the "official" response to section 6.6. Why? Because it's much easier for a company to demonstrate that it has a properly configured Web application firewall in place than to demonstrate that the existence of a rigorous program of Web application assessment. There's simply less subjectivity, making it easier for an assessor to check the "In place" box on your company's report on compliance (ROC).
Another important use of the Web application firewall is to provide "virtual patching" of known Web application vulnerabilities. For example, an organization might use a Web application firewall to block requests that would exploit a known SQL injection bug in vendor-provided code. As the organization has no ability to create a patch for the vendor's application, a Web application firewall can obviate the need for the patch by blocking the suspect requests before they reach the application.
Implementing a Web application firewall
This strategy does have limitations, however. First, be sure that the WAF rules put in place are custom-tailored to each known vulnerability and are as broad as possible to block an attack without preventing critical business activity. This requires careful analysis by a security professional on a case-by-case basis, as every vulnerability is slightly different. Document the results of this analysis and provide it to PCI DSS auditors if they request it. Finally, keep in close contact with the vendor to determine when a patch is available, and apply it within the PCI DSS-mandated one-month window.
Also consider submitting WAF rules to your merchant bank as a formal compensating control for PCI DSS section 6.5 if a vendor patch is likely to be a long time in the making. This will go a long way toward satisfying auditors' stringent demands for documented compensating controls and limits liability if a compromise does occur.
No substitute for good development
It's important to keep in mind that, while Web application firewalls can help block inbound attacks to an organization before they reach the Web server, they are no substitute for good development practices. No information security control is 100% effective, and that includes Web application firewalls. Some dangerous requests will slip through the cracks and, for that reason, it is essential to develop robust code that is capable of standing up to an attack. Web application firewalls are simply another layer at an organization's disposal when building a defense-in-depth strategy for Web app security.
Developers can protect against vulnerabilities in their applications by integrating information security controls into each phase of their software development lifecycle (SDLC). NIST provides some great guidance to help do so. Here are some highlights worth mentioning specifically:
- Initiation stage -- Developers should engage security experts and ensure that they have detailed the confidentiality, integrity and availability concerns alongside of the other business requirements for the application. This phase should also include a preliminary risk assessment.
- Development stage -- Risk assessments should continue, and developers should select the security controls they will incorporate into their code and validate those controls during unit testing.
- Implementation phase -- Security control integration and acceptance testing should take place.
- Operational phase -- Throughout the time an application is in use, enterprises should incorporate change management, auditing, incident handling and intrusion detection procedures.
- Sunset phase -- Organizations must consider the proper disposal of sensitive information.
Developers who embrace this approach and incorporate good development practices using a lifecycle approach are much more likely to build robust applications that stand up to common Web threats.
The bottom line is Web application firewalls play an important role in safeguarding today's Web applications against current and emerging threats. Combined with a strong SDLC process that incorporates risk assessment and testing, WAFs can serve as the cornerstone of a solid defense-in-depth approach to Web application security in the enterprise.
About the author:
Mike Chapple, Ph. D., CISA, CISSP, is an IT security manager with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com, and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He is a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Study Guide and Information Security Illuminated.