Web Application Firewalls Aren’t the Enemy of the Software Development Lifecycle. Putting a WAF Place Can Help Expedite the SDLC.
There is an unnecessary war going on in the world of application security, and not just between security pros and hackers. The gulf we are going to talk about today exists between secure development evangelists and proponents of Web Application Firewalls (WAFs). Advocates of secure development say that proponents of WAFs, which focus on protecting the applications from malicious exploits, are pushing a technology that is simply a band-aid for applications that need to be fixed as part of the System Development Life Cycle (SDLC). Some even go as far as placing WAFs on the lowest rung of the respect ladder, considering them only as a tool to appease auditors (think PCI, which calls out the use of a WAF or code review). Some prefer to express their opinions in bypassing the issue. For example, one SDLC framework, the Building Security in Maturity Model (BSIMM), only mentions WAF four times in 56 pages.
Meanwhile, Web application firewalls advocates are cheering on the other side of the bleachers, quoting a 2010 report from Forrester Research that states: “ultimately it is the WAF’s security capabilities that land it a spot in an organization’s network infrastructure.” Analyst reports show both markets growing nicely. An August 2010 report from the 451 Group showed that WAF growth at 27% CAGR is faster than code review’s 18%. But why should these approaches be mutually exclusive? This week, we will discuss why these two approaches should be integrated to improve your application security posture.
Key Issues with SDLC alone
While developing secure code and plugging security holes are part of security development best practices, organizations are still struggling to get this right for a number of reasons:
• Developer acceptance. Developers focus on positive functionality – releasing the best application with the best features. For them, security can sometimes be considered a nuisance that interferes with deadlines and often requires executive mandates to change behaviors. Among the developers, security expertise and training are lacking. Today’s training approaches are manual and time consuming. That being said, there are attempts such as WebGoat which is a platform individuals can use as a test-bed for their security training. Jerry Hoff is an active developer of this project and I very much recommend checking out his educational videos which provide good overviews on common security issues and secure coding practices. Unfortunately, reality proves that we are still far from achieving widespread secure Web applications.
• It’s expensive. According to Adrian Lane, an analyst with data security firm Securosis: “With the exception of Oracle, budgets for tools and training were just a step above non-existent.” In fact, take a sample of companies featured in the BSIMM software security framework, you’ll find companies such as Adobe, EMC, Microsoft, Standard Life and Wells Fargo. The smallest market cap on the list? $23B. In addition, consider that the cost of fixing vulnerabilities is estimated at $28K in outstanding insecure software debt.
• Not enough instant gratification. Until recently, Cigital, an SDLC consultancy, featured a case study on their website stating: “The “SDL” program was created as a three-year program run out of the information security office.” [Emphasis mine]. By contrast, the average CISO tenure is 2-4 years (according to Gartner), or even as low as 18 months (Forrester’s estimation). Though important, SDLCs require patience and implementing a three-year project in today’s volatile security environment is challenging—especially in the high stakes game of data security.
• More vulnerabilities than time. Last year, WhiteHat Security estimated that websites, on average, have 230 vulnerabilities. Code analysis vendor Fortify released a case study that identified as many as 10,000-20,000 issues in large applications. With such a massive amount of vulnerabilities and issues it is easy to be overwhelmed.
• Don’t always have the code. How can you go about fixing code you don’t have? Nothing better exemplifies this problem than the blog dispute between Oracle and Veracode last summer on the value of third-party code analysis.
• Some issues don’t need vulnerabilities. Take for instance security issues which plague online availability such as regular and application DDoS. The latter consumes server-side resources by inundating it with requests that require much processing on the server’s end. Business Logic Attacks exploit the logic flow of the application- it is not a direct attack that exploits a specific security vulnerability. These types of attacks force the usage of external modules and even tools to correctly address them.
Enter the WAF
WAFs are designed to protect applications by providing multiple layers of protection, such as protocol validation which detects HTTP protocol violations (think a car receiving a speeding fine on the way to a bank heist), as well as analyzing attack signatures to identify known attacks, application profiling to detect abnormal application usage, data leak prevention and even reputation-based services to stop attacks before they are launched.
How can this protection be applied to the SDLC?
• Instant gratification. Virtual patching reduces the window of exposure while patches are thoroughly tested and deployed. In other words, have the WAF to immediately patch the vulnerability and reduce the security risk. In the meanwhile, the organization can proceed to fix the security issues on its own schedule without emergency fix and test cycles.
• Threat modeling. What’s a better way to model threats with threats themselves?! A WAF deployment allows for visibility into attack traffic that in turn helps to gather attacker intelligence that can be added to your test cases when building the software.
• Expedite developer acceptance. According to BSIMM, a best practice is to “identify software defects found in operations monitoring and feed them back to development.” In effect, this type of activity gives training a context in reality.
• Prioritize remediation. Due to the amount of vulnerabilities, organizations need to decide what to fix first. Looking into the attack traffic enables you to understand what hackers are hacking and build a reasonable schedule of fixes. A WAF can provide that visibility.
• WAF with vulnerability scanning. The benefits of scanner integration include more granular control over security policies, visibility into user activity and attempts to exploit vulnerabilities and immediate remediation from known vulnerabilities. Gartner analyst Neil McDonald called this type of security marriage “Security No-Brainer #9: Application Vulnerability Scanners Should Communicate with Application Firewalls.”
• Protect apps when you don’t have the code. Since the WAF is focused on protecting the application, this is actually inherent to this type of defense.
• Report progress to management. Unfortunately, security is still considered the underdog. How do you actually prove the need for secure development and testing or even the results of your progress? Readable WAF reports can provide the necessary dashboard showing the threat landscape – from a high level overview of current attacks to the most attacked URLs.
Accelerating SDLCs with WAFs
In conclusion, it’s all about changing perception. WAFs are not the enemy of the software development lifecycle. In fact, putting a WAF into place will actually allow you to expedite the SDLC. It allows you to gain that extra visibility into actual threats, which reduces guess work and provides some much needed protection as developers go ahead and remediate the code.