Thursday, September 17, 2009

Making Web Application Security Controls Repeatable

Raul Siles recently posted a useful reminder as his ISC diary post - "Review the security controls of your Web Applications... all them!". He used the problems described by Ryan Barnett that were found in Yahoo's web API as an excellent example of this rule. Both posts point to a common problem in applications that I see - the loss of established controls in new code and new functionality.

One way I've been working to help fix this in an organization that hasn't developed a comprehensive software develoment lifecycle or broad QA process is to build a multi-step process to handle security flaws found in an application. Typical steps are:

  1. Determine whether the problem is unique to the application, or if it is a flaw that is likely found in other applications, either current or future.
  2. If it is more than a one time problem, design a common library or technique to handle the problem.
  3. Assess the severity of the problem, and apply the fix to other applications if the risk is determined to be high enough to justify the effort. If not, add the fix to the queue for the next update to those applications.
  4. Re-test the application to verify that the fix works.
  5. Document the library and ensure that the rest of the team is aware of it.
One of the best things about this sort of process is that developers start to think about problems in a much broader context. Recently, I've seen two of the developers I work with frequently stop during a meeting and ask out loud "I wonder if that applies in application X too...". That thought process usually ends up in modifications to their standard application libraries which means that problems I saw once tend not to come back across their entire group.

How are these vulnerabilities discovered? A web application vulnerability scanner - WebInspect in this case - provides most of the vulnerability testing. Manual testing, while often deeper and more likely to find corner cases for vulnerabilities doesn't scale as well into an environment with limited resources and a large number of applications. Automated testing systems are also great to help cover some gaps in skillset. As Jeremiah Grossman points out, they may simply cover low hanging fruit, but that can be very valuable.

Do you have a unique or creative internal process to make sure that your organization keeps web application vulnerabilities from recurring?

No comments: