Web Application Firewalls Take Some of the Pressure Off App Dev Teams

Various studies have shown that it costs 30 to 60 times more to remove a security vulnerability from a production application than it does to address the vulnerability during the design phase. Nevertheless, many organizations fail to incorporate security into every phase of the software development lifecycle (SDLC). Creating an SDLC for operational purposes is hard enough, but add security gates to the complexity and the wheels often fall off.

Web application security is particularly critical but often neglected. Web application security threats are well known — cross-site scripting, SQL injection and remote code execution, just to name a few. Nevertheless, attacks that exploit these vulnerabilities remain painfully common, and the victims often are organizations that should have known better.

The following security gates should be followed to ensure that your web application does not suffer a data breach:

Delivery Process

Security Gate

Build & Integration

Static Code Analysis Tools

Quality Assurance

Web Application Vulnerability Scanners

Staging and Pre-Production

Runtime Application Self-Protection

Production

Penetration Testing and Vulnerability Scanning

In SageNet’s experience, many organizations struggle to implement a full-featured delivery process in the real world. Staffing levels, computing resource availability and business expectations for features are common excuses for this problem. On the other hand, many organizations are just one security breach away from disaster. So, with limited time and budgets, what is the top priority?

A web application firewalls (WAF) can be the quick fix we’re all looking for. WAFs monitor the communications between a web application and the user’s browser, looking for and blocking malicious traffic. They run checks on incoming traffic to prevent injection attacks, intercept sensitive outbound data to prevent data leakage, and control the rate of requests to prevent application-layer denial-of-service (DoS) attacks.

The most interesting new development in the WAF space is the use of a positive security model in identifying traffic. This is where the WAF learns what is normal for your application and prevents all other actions. A signature-based model, in contrast, often leaves gaps in coverage.

Organizations traditionally have implemented WAFs to help meet regulatory compliance requirements. For example, requirement 6.5 of the Payment Card Industry Data Security Standard (PCI DSS) discusses 10 of the most common coding vulnerabilities and techniques that can be used to avoid them. Requirement 6.6 talks specifically about the risks posed by public-facing web applications, and how WAFs can help to reduce those risks.

A WAF is not a substitute for secure coding practices. However, it is the fastest way to prevent a wound or stop the bleeding from your internal or external web applications. It can also minimize the amount of ongoing manual labor required to keep up with these security threats.

Even with a fully secure SDLC, vulnerabilities are going to crop up that have never been seen before. Somebody is going to code something incorrectly or fail to test thoroughly. By building upon your security model, a WAF helps to relieve some of the pressure on your software development team.

There are a number of WAFs on the market, and each takes a slightly different approach. How do you choose the best one for your needs? At SageNet, we have a new partnership with a WAF vendor that we think is the best in this business. Call us and we will schedule a review of the technology and drive toward enhancing the security of your web applications.