The Web application industry is seeing the convergence of two major strategies take place: the increasing need...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
for Web application security as well as the increasing application of Agile development methodologies. Many see these strategies as contradictory – while many Agile lifecycle teams deliver rapid software releases, their code contains numerous security vulnerabilities. Contrary to what many believe, the two are not mutually exclusive: it is possible to develop applications within the Agile methodology while implementing and following a secure development lifecycle. In this article, I will present ideas that teams can use to accomplish these two goals.
A secure development lifecycle is the combination of processes, methods, tools and technologies which are leveraged to produce secure (or more secure) applications. While a number of methodologies are published and in practice today, I find that a combination of the Microsoft Security Development Lifecycle and the “Building Security in Maturity Model” (BSIMM) is a great way to approach improving software security. The Microsoft SDL covers practices which roughly correspond to Waterfall lifecycle components: training, requirements, design, implementation, verification (testing), release and response. (Note: don’t panic—this article is about incorporating these practices into Agile methodologies). The BSIMM documents approximately 130 security best-practices followed by the top software organizations in the world, independent of development methodology.
In a Waterfall world, the BSIMM activities and the Microsoft SDL map neatly to the common phases of software development. According to a Microsoft SDL article about Agile and SDL, the best approach to mapping these activities into an Agile world is to divide them into categories: activities which must happen regularly, activities which should happen often but not necessarily every sprint or even every release, and activities which only need to happen once. I disagree with Microsoft’s final category: especially in industries where compliance is required, this category of activities often needs to be repeated on at least an annual basis (somewhat in violation of the Agile principle of doing the least amount of work necessary to complete the story, compliance often requires re-work simple to check a box).
Let’s examine each category and describe activities which might take place:
At the top of my list for regular activities is the application of secure code analysis tools. There is no more effective way of measuring code security and detecting security flaws than the use of ‘second generation’ automated static code analysis tools. Sadly, the open source world lacks any significant contribution to this requirement, but companies committed to delivering secure code must give serious consideration to purchasing a commercial application for this purpose. Secure code analysis tools should be run at least daily against every build, if not integrated directly into the build process, and “critical” or “high” vulnerabilities should be considered build-breaking events.
Another activity which should be performed regularly is the authoring and application of ‘abuse stories’ (security-related user stories which explore ways in which an application can be misused or attacked) in every release. Other activities include penetration testing to cover user stories and development tasks for the current sprint.
One thing to keep in mind about the convergence of security and Agile development is that Agile generally focuses on limiting change to specific areas, thereby reducing the impact of change. Security isn’t often as focused; because attackers leverage attacks across an entire application, security must be approached with a holistic view even in Agile lifecycles. In short, it is important for Agile teams to stop and think about the security impact of changes in the current sprint, and ensure the appropriate design, implementation and validation techniques are leveraged. This aids teams in improving overall application security.
While a tenant of Agile is to always build releasable code, not all teams release every sprint (this is generally due to process-related release ‘taxes’ such as deployment preparation, release testing and customer interaction and preparation). “Occasional Tasks” are SDL-related tasks which are generally associated with a given release but may also be associated with contractual or compliance obligations. These tasks are generally the greatest challenge for an Agile team, because the Agile team is typically focused on the day-to-day backlog items. Agile team leadership need to be aware of these occasional activities, and must ensure these activities are added to project backlogs appropriately.
Some examples of occasional activities include:
- Application-wide penetration testing (manual or automated).
- Feature-specific threat modeling.
- Release-readiness validation such as disabling of tracing and debugging configurations, or the application of custom error pages in Web applications.
- Fuzz testing and other destructive testing methodologies which would span discrete application functionalities.
- Code review for new or high-risk code.
Appendix Q of the Microsoft SDL Agile Guide offers a long list of occasional activities broken down into planning, design and verification buckets.
Finally, Agile teams need to be cognizant that a number of one-time activities need to be performed to set or maintain the standard for security within a project. These activities typically occur at project kick-off, when a project is migrated to an Agile methodology, or when an Agile project undergoes its first security pass. Whereas Microsoft categorizes these activities as one-time validations, I believe some need to be repeated. These activities include validating base architecture, identifying security and privacy contacts, ensuring approved frameworks and compilers are in use, identifying and validating libraries, and so forth. As minimum standards are constantly changing, not all of these activities are one-time events (for instance, if an open source library is leveraged within an application, and the minimum version of that library changes due to security fixes, the open source library must be updated—detecting these update requirements is an ongoing process).
While this is just a short overview, this article demonstrates how Agile and secure coding methodologies can be synthesized to increase the security of applications developed within the Lean Agile methodology. With some careful planning, teams can begin to integrate the daily, occasional and infrequent activities which are necessary to produce secure software. By introducing these security processes and activities, Agile teams can continue to benefit from the rapid, efficient development methodology while releasing increasingly secure applications.
For further reading:
Microsoft Security Development Lifecycle: http://www.microsoft.com/security/sdl/default.aspx