This is a guest posting by Michael Solomon PhD CISSP PMP CISM
Agile software development has gained tremendous popularity since its introduction as an approach that emphasizes efficiency and timely responsiveness to customers’ needs. VersionOne publishes an annual survey of organizations using agile that explores their goals and how well agile helps to meet these goals. The latest is the 12th Annual State of Agile Report, which shows that agile consistently provides customers what they want, when they want it, while requiring less time and cost commitment from the software producers.
Although agile is wildly popular and generally accepted as being effective, it doesn’t help software developers address most security concerns. The problem of insecure software isn’t a weakness of agile; it is a result of how agile is used.
In agile, user stories provide the specifications for software developers to know what to do. Approved user stories are added to the backlog, which is simply a list of user stories that haven’t yet been addressed. Many software developers view security qualifications as nonfunctional requirements, and nonfunctional requirements are depicted as constraints on the backlog, as opposed to separate user stories.
Because security concerns aren’t expressed as user stories, the perception is that adding security features slows things down. So as organizations move to agile software development, security often gets left behind.
Get TestRail FREE for 30 days!
Why Isn’t Agile Software Development Already Secure?
In the waterfall method, security planning generally takes place during the initial design phase (or at least, it should). Security is baked in up front and is part of all activities that occur after the design phase. Then, the post-development activities include security testing in the overall functional testing phases.
Security testing validates that the security design goals have been met, along with functional design goals. This approach has the advantage of enforcing application or enterprise-level security policy across all developed software. Further, the post-development testing can validate that security is implemented uniformly across the application.
Agile uses a different approach for software development. Software products are decomposed into multiple builds, and activity to create these builds are called sprints. Sprints are focused on producing narrowly scoped deliverables in a short time frame, commonly two weeks. That means the emphasis is placed on simply satisfying user stories. In other words, success depends on producing a deliverable that meets user story requirements in two weeks or less. Satisfying extraneous constraints is a nice goal, but it’s not always a “front of mind” task for software developers. That’s why security generally isn’t a primary design goal in agile.
Developing Secure Applications with the Agile Methodology
You can develop secure software and use agile. It just takes a slightly different approach to the overall development process, especially how backlogs get built.
Early on in agile history, researchers realized that new techniques were needed to ensure secure software when using agile. In 2005, Mike Siponen, Richard Baskerville, and Tapio Kuivalainen published an academic paper, “Integrating Security into Agile Development Methods.” The authors describe the problems with using traditional security approaches in agile development and then propose techniques for integrating specific security features into the development process.
A more recent paper shows that the problem is still one to consider. In 2013, Davoud Mougouei, Nor Fazlida Mohd Sani, and Mohammad Moein Almasi published the paper “S-Scrum: a Secure Methodology for Agile Development of Web Services.” The authors define a security-focused implementation of Scrum, called S-Scrum, that incorporates security best practices into agile. These papers point out that security problems are real, but viable solutions to them exist.
There is also a growing number of industry resources that focus on secure agile application development. For starters, Microsoft documents the Software Development Lifecycle (SDL) for Agile. Microsoft has decomposed the most important tasks related to software development and mapped each one to a specific phase in the agile method. Tasks, or best practices, are mapped to one of three categories:
- Every-sprint practices: Tasks that should be carried out for each sprint
- Bucket practices: Tasks that should be carried out on a regular basis but need not occur in every sprint
- One-time practices: Basic tasks that must be carried out once for each project
Their guide should be a mandatory document for any agile shop. You don’t have to implement everything, but you should at least compare Microsoft’s approach to your own. It is a great checklist to ensure that you aren’t omitting any foundational best practices.
Another great resource for secure agile development best practices is the Open Web Application Security Project (OWASP). OWASP debuted in 2001, the same year the Agile Manifesto was published. The site has a very good resource that addresses agile and security: The “Agile and Secure: Can we do both?” presentation covers best practices for developing secure web applications in an agile environment. Instead of categorizing security task like Microsoft does, the OWASP approach is to describe how the agile method should be extended to include security.
Most approaches to developing secure applications in agile focus on a single foundational aspect: creating security-based user stories. Considering user stories are the drivers for sprint activities, it makes the most sense to include user stories that meet security goals. By adding comprehensive security-based user stories to the backlog, the agile process drives the inclusion of security in each sprint.
For example, in addition to functional user stories in the form of “As a , I want so that ,” it is imperative to include user stories that address security-related roles. They could include user stories such as:
- As a hacker, I can input data that is too long and cause unexpected data to be returned
- As a hacker, I can send input that terminates a SQL query and adds additional SQL queries to return unauthorized data
- As an architect, I want to ensure all output is properly encoded
There are many security-related user stories you could add to each sprint. The OWASP site contains an article about evil user stories, and the software assurance nonprofit SAFECode published a paper detailing many more types of security user stories and tasks. These are both great resources to get you started with adding security-centric user stories.
The most important takeaway is to realize that just by adding security to user stories, you can make a dramatic impact on the security of your software development process in agile.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
The Most Important Next Steps
Once you have decided to pursue secure software development in agile, you should get started right away to make it happen. Here are a few of the most important steps to take next:
- Add security-related user stories to your backlog
- Implement automation whenever possible to carry out repetitive tasks (especially testing)
- Educate developers on how to write secure applications
- Develop and publish your own organization’s secure best practices
- Empower developers to take responsibility of application security
- Be flexible and continuously build a culture of security
These are rather general goals, but they provide the overall direction for making your software more secure.
Developer education is of critical importance. All software developers must be well-versed in developing secure application software — and given the ability to take responsibility for doing so. Testing should primarily exist for the purpose of functional and security validation.
If you commit to making inclusion of security a priority, agile can provide a framework that results in the most responsive, functional and secure applications your organization can produce.
Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.
Test Automation – Anywhere, Anytime
