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:
- 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.
- If it is more than a one time problem, design a common library or technique to handle the problem.
- 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.
- Re-test the application to verify that the fix works.
- Document the library and ensure that the rest of the team is aware of it.
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:
Post a Comment