I have been re-reading Martin Fowler's seminal essay The New Methodology where he outlines the reasoning for Agile methodologies. The focus of the article is on the adaptive nature of Agile methodologies and their people-first orientation. The article is fantastic but it is telling that a search for the words "security" and "secure" turns up no matches. As with the principles of the Agile Manifesto I wanted to step through this document section by section and see where security needs to get involved.
First up is the section "From Nothing, to Monumental, to Agile"
One of the legacy practices that is maligned in the article is the tendency for traditional development methodologies to have a long testing phase at the end of a development cycle. In a lot of organizations, this is where "security" gets implemented by either talking to the infrastructure team about firewall rules or if an organization is really trying hard they'll run a scanning tool or hire a firm to do an application pen test. The problem with this is that finding security bugs at this point blows up the project - either the release is delayed while the security flaws are patched or the application goes live with known security issues. The Agile folks want to roll a lot of the quality testing into the process on a day to day basis rather than bunch it all up at the end and from a security standpoint this is a fantastic idea. Paying attention to security every day of the development cycle is going to produce better results than tacking security on at the end.
Another issue the article raises is the weight that documentation requirements and other tasks add to traditional methodologies. Agile methodologies seek to strip out all tasks that are unnecessary to the point that the documentation is the actual software source code. I think everyone would agree that most traditional waterfall methodologies are too document-centric and this hinders team productivity and responsiveness. However, design level documentation can be very important for security in that it helps to capture not just what decisions are made (the source code does this the best) but also why decisions were made. Understanding this context is often key because misunderstanding it leads to poor decision making and logical application flaws. The ability to adapt and change is great, but doing this without a solid understanding of the security context in which you are operating is a recipe for disaster.
Finally, the article makes the point that no process will ever make up for the quality of the development team. Process and structure help to enforce consistent results, but they will not substitute for talented and well trained developers. I've heard it said before: "You can't patch stupid" This is becomes even more true in Agile development environments where you take away a lot of the process safety net. You can't have a review team inserting themselves every step of the way to make sure you followed the process to the letter if you ever expect to ship useful, working software. Agile teams raise the bar on the skill level and "engagedness" required of the team members. If you want your Agile team to build secure software then every person on the team needs to understand secure coding and risk assessment because the responsibility will fall on them to make good decisions, day in and day out.
Comments