Building a Better Web Application Security Practice

Web application security is hard. It will never be as simple as scanning for open ports and applying the correct source and destination IP address filters. I don’t mean to say that network security is easy, but in comparison to web application security, locking down the network is a pretty straightforward task. Unfortunately, because we have become so proficient at protecting ourselves at the network layer, attacks are now moving up the stack. Attackers are targeting not only the application but also intermediate layers like SSL/TLS encryption. So we must expand our security practices to include these additional attack vectors.

If web application security is hard, then we must find ways to be practical in our approach. The most daunting part of web application security is in getting your team to accept and adopt application security as part of their practice. Responsibility not only falls on security engineers and architects but also on the over-burdened shoulders of our teammates in application development. Developers are more readily incorporating secure coding practices in the creation of web applications, thanks to the work of OWASP and vocal evangelists like Jim Manico.

However, even with better coding practices, there often remains a great divide between developers and security practitioners within many organizations. The security team might be running application security scans, looking for vulnerabilities in run-time code—and these scans are often done in addition to scans run by the developers themselves. Reconciling the vulnerability reports between these various scans, validating the vulnerabilities, and then prioritizing them is yet another task that often has no clear-cut ownership or at best has dual ownership.

In addition to these application security testing (AST) solutions that scan web applications for both dynamic (run-time) and static (source code) vulnerabilities, in-line security appliances such as web application firewalls (WAF’s) can be leveraged to apply virtual patches for discovered or known vulnerabilities. But converting AST-generated vulnerability reports to WAF policies can be time-consuming—potentially as time-consuming as remediating the code itself. For a WAF or AST to be a valuable part of your application security practice, these tools must be able to shorten both the time to discover vulnerabilities and the time to remediate them. The goal of these tools is ultimately to shrink the risk window for deployed web applications.

Jeremiah Grossman and others recently debated openly on Twitter whether DAST or SAST were the more important tools for effective web application security:

The purpose of finding website vulns, predominently w/ Dynamic Analysis, is so bad guys have less to exploit.

— Jeremiah Grossman (@jeremiahg) October 9, 2014

This presentation by Chris Wysopal and Gordon MacKay from RSA 2013 is an excellent primer on SAST, DAST, and vulnerability management; it argues effectively that both SAST and DAST are necessary. As Richard Hack rightly noted in the Twitter debate, “Security costs… cutting corners doesn’t work.”

Perhaps the most vital tool in our web application security arsenal is logging and log analysis. Ryan Barnett of Spider Labs is a lead on the ModSecurity open-source WAF project and the author and teacher of the Web App Defender Cookbook. As he puts it, “logging and alerting is not a luxury” in defending a web application. Analyzing live traffic to understand what attack vectors are being employed and what vulnerabilities attackers are attempting to exploit is indispensible knowledge in the implementation of an effective web application security practice.

There are many security information and event management (SIEM) solutions available. When choosing a SIEM with web application security in mind, the ability to parse full HTTP requests and not just violation data is crucial. The SIEM should also ideally support the other components of your web application security infrastructure, including AST, WAF, IPS, database firewalls, and traditional network firewalls.

So, we have AST, WAF, secure coding, SIEM, and vulnerability management as key components to an effective web application security practice. We also have the amazing resources provided by OWASP, such as their essential Cheat Sheets, which are a must-read for application security stakeholders, including security, app dev, sys admin, and even network teams. The question that remains is: how do we successfully integrate these tools and knowledge to build our own web application security practice?

The answer may seem obvious, or even over used. We must make application security an integral part of existing processes, to ensure adherence and to create accountability.

Within the software development lifecycle (SDLC), there are multiple steps that would enable us to integrate AST, WAF, and vulnerability management into existing secure coding practices. As vulnerabilities are discovered (in QA, Staging, or Production), whether via AST tools or code review, the option exists to remediate the vuln in code, or mitigate via a WAF. Fortunately, many WAF solutions offer automated conversion of vulnerability reports into mitigating policy, shrinking the risk window considerably. The vulnerability management program must assess the severity of each vuln against the risk window associated with code remediation and WAF mitigation. The vulnerability management team must then decide which option best serves the security goals of the organization. The SDLC is an ongoing process, and must include both legacy web apps no longer under development as well as new and constantly evolving web apps.

When application security stakeholders from the various teams engage in the SDLC and vulnerability management processes, we are more able to identify, adapt, and respond to the inconstant nature of both attacks and vulnerabilities.

How is your organization tackling the challenge of web application security? What obstacles have you encountered in building a better web application security practice? How did you overcome them?

I look forward to your comments below and interacting with you on Twitter.

[su_box title=”About Brian A. McHenry” style=”noise” box_color=”#0e0d0d”]

As a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.

Twitter: @bamchenry[/su_box]