From: Securosis Highlights – Pragmatic WAF Management: Application Lifecycle Integration

Posted on 2012/08/16


a quick re-post from Securosis Highlights https://securosis.com/blog/pragmatic-waf-management-application-lifecycle-integration

Pragmatic WAF Management: Application Lifecycle Integration by (author unknown)

As we’ve mentioned throughout the series, the purpose of a WAF is to protect web facing applications from attacks. We can debate the build security in versus bolt security on approaches ad infinitum, but ultimately the answer is both. We discussed in the last post how to build and maintain your WAF policies to protect the applications, but you also need to adapt your develop process to incorporate knowledge of typical attack tactics into code development practices to better address application vulnerabilities over time. This involves a two-way discourse between the WAF administrators and developers. Developers do their part helping the security folks better understand an application, what input values should look like, and what changes are expected in upcoming releases. This ensures the WAF rules remain in lockstep with the application.

Granted, not every WAF user will want to integrate their application development and WAF management processes. But candidly, that necessarily limits the effectiveness of both the WAF and puts the application at risk. At a minimum the developers (or DevOps group) should have ongoing communications with WAF managers to avoid having the WAF complicate application deployment and to keep the WAF from interfering in normal application functions. Given our view of the critical of this collaboration, let’s dig into how this lifecycle can (and should) work.

Your web applications constantly change, especially given increasingly ‘agile’ development teams, some pushing web application changes multiple times per week. In fact, many web applications development teams don’t even attempt to follow formal release cycles, resembling more of an ‘eternal beta cycle’. The team’s focus (and incentives) involve introducing new features as fast as possible to entice more customer engagement. Obviously this doesn’t help any attempts to secure the application, and provide a serious challenge to keep a WAF’s policy base current and effective.

To be more specific, the faster the rate of application change, the harder it is to maintain WAF policies. This simple fact really complicates one of the major selling points of a WAF, the ability to implement positive security policies based on acceptable application behavior. As we explained in the last post, the white list policies represent the acceptable commands and their associated parameters. The WAF learns about the web applications it protects by monitoring user activity and/or by crawling the application pages, determining what pages need protection, which serve static and/or dynamic content, the data type and values ranges for page variables, and other aspects of user sessions. If the application undergoes constant change, the WAF is always behind, introducing a gap between learning and protecting. Changing application behavior isn’t factored into the WAF policies, which results in legitimate requests to new pages being blocked, or illegal requests being ignored. That kinds of defeats the purpose of the WAF, no?

To mitigate these issues, we have identified a set of critical success factors for integrating with the SDLC (software development lifecycle). When we originally outlined this process we mentioned the friction between developers and security teams and how this adversely effects their working relationship. Our goal here is to help set you in the right direction and stop the different groups from feuding like the Hatfield’s and McCoy’s; trust us, it happens. Here’s what we recommend:

  • Executive Sponsorship: If, as an organization, you can’t get developers and operations in the room with security, the WAF administrators are left on an island. It’s up to them to figure out what an application is supposed to do, how it should be protected, and they are constantly reacting to change without proper insight or perspective. Similarly, if the development team can say ‘no’ to the security team’s requests, they usually will; they’re paid to ship new features, not assist security. So either security is important or it isn’t. To move past a WAF only useful for compliance, security folks need someone up the food chain, the CISO, the CIO or even the CEO to agree that the velocity of feature evolution must give some ground to addressing general operational security. Once management has made that commitment, developers can justify improving security as part of their job. It’s possible – and in some organizational cultures advisable – to include some security into the application specification. In essence this helps guarantee code does not ship until it meets minimum security requirements, either in the app or in the WAF.
  • Establish Expectations: Here all parties learn what’s required (and expected) to get their jobs done with minimum fuss (and maximum security). We suggest you arrange a sit down with all the stakeholders (operations, development and security) to establish some guidelines on what really needs to happen, and what would be nice to have. Most developers want to know about broken links and critical bugs in the code, but they get surly when you send them thousands of changes via email, and they get downright pissed when all the requests relate to the same non-critical issue. It’s critical to get agreement on what makes a critical issue, and how critical issues will be addressed among the pile of competing critical requirements. Set guidelines in advance, so there are no arguments when issues arise. Similarly, security people hate it when a new application enters production on a site they didn’t know existed, or significant changes to the network or application infrastructure happen that breaks the WAF configuration. Technically speaking, each party removes work the other does not want to do, or does not have time to do, so position these discussions as mutually beneficial. A true win-win.
  • Security/Developer Integration Points: The integration points define how the parties share data and solve problems together. Basically establish the rules of engagement for how DevOps works with the WAF team, when they meet, and what automated tools will be used to facilitate the communication. You may choose to invite security to development scrums, or conversely a member of the development team to security meetings. You need to agree upon a communication medium that’s easy to use, establish a method to get urgent requests addressed, and a means of escalation if/when they are not. Associated logical (and documented) notification processes need to be integrated in the application development lifecycle to ensure the security team understands application changes, so they can adjust polices in advance. There needs to be a logical (and documented) process for application deployment that signals when to update the WAF policies and propagate across WAF systems. In the rare cases where your pre-production test environment uses a WAF to help certify production deployment, use this opportunity to have the WAF learn about the application changes. Don’t forget the beginning and end of the process as well, including design and development, as well as pre-launch validation steps. Without formal security involvement, inevitably these steps will be skipped – especially at crunch time. Go back to point 1 above and start over again if that happens.
  • Automation: This is where you implement and automate the results from steps 2 and 3. Once the initial work is done, these processes need not be painful, and don’t even need to happen face to face. After the initial meetings, most of the cooperative efforts can be done via less formal means – email, bug tracking software, trouble ticket systems or even source code management. Even with executive sponsorship and clearly documented integration points, without sufficient automation of security functions (scanning, testing, regression, etc.), things will be difficult to operationalize. Look to make things easy, where possible. Keep in mind the importance of the WAF team filtering out noise before it gets to the development team, and to keep focused on actionable information. On the other hand, the development teams needs to provide enough information so the WAF manager knows what’s going on and can get their job done.
  • Feedback Loops: Once the process is established, then look for ways to improve it over time. We’ve seen, after the first few development cycles have passed, the value of discussing ways to make the process easier and more efficient for all parties. Don’t be bashful about sharing what you learned. For example, if the WAFs blocked attacks that can be easily mitigated with a simple change to the application, it’s in every one’s best interest to share that data. Our research also showed the value of this collaboration as the application development team matured their code, which in turn helped the WAF perform better. Nothing turns off either side faster than feeling unappreciated, and this is the time to show your value and show how the process makes things easier. Sure, that’s soft and straight out of a new-age success manual, but it’s still true.

As we said before, our focus in this post was on the relationship between app developers and WAF administrators. That said, lots of people who end up managing WAFs have some development background, as it’s difficult to write WAF policies without understanding the intricacies of web communication protocols and how web services work. And some of the folks we’ve spoken with had no trouble integrating as part of the DevOps team, given their development background provided sufficient credibility.

In our next post we’re going to cover the issues with WAF deployment and how to avoid exposing applications – and the WAF itself, to attackers.

– Adrian Lane
(0) Comments

Posted in: reading