SEATTLE -- Can you be agile and secure?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
That's the dilemma agile software developers face as they build flexible, responsive applications. But it is possible, according to Dan Cornell, principal at the Denim Group. Some compromises just need to be made.
Organizations are being pulled in two directions, Cornell told attendees of the 2006 AppSec Seattle conference. On one side you have the agile forces where developers are more responsive to business concerns, the frequency of stable releases is increased, and the time it takes to deploy new features is decreased.
On the other side you have the security forces that call for a more aggressive regulatory environment, an increased need for security and traditional top-down, document-centric approaches.
"Unfortunately it puts the two forces opposite each other," Cornell said. "There are going to be trade-offs that need to be made."
The challenge is to take the good things out of the Security Development Lifecycle, such as threat modeling and application testing, and add them to the agile method, he said.
Start with the project setup, Cornell said. When considering education and training for developers, testers and users, include security. Then following your user stories, use case development and architecture decisions, agree on threat modeling standards for the project -- STRIDE priorities or DREAD ratings.
When you move into the release planning phase, as you do your user stories and use cases include concerns, Cornell said. Consider inputs for threat modeling, security testing scenarios and determine the qualitative "risk budget."
"Developers and customers need to agree at the outset what is expected," Cornell added. "Keep the customer involved in making risk trade-offs."
As you finalize architecture and development guidelines, include security in your common coding standards. During this phase you should also conduct initial threat modeling and create a designer's security checklist, he said.
In addition to the traditional project roles of product manager, program manager, architect, developer and tester, Cornell said it's important to designate someone as the security adviser. That person will keep track of what was determined through threat modeling.
Planning, executing and closing an iteration
Security also comes into play during the iteration planning phase, which is usually one to four weeks. At the iteration planning meeting where user stories are broken down into development tasks and developers estimate their own tasks, you need to also document the attack surface or story level.
Cornell said you should also model the threats alongside the user story documentation. This is important in documentation-light processes. "Your code will tell you what decision was made, and threat models will tell you why decisions were made," he said. "It's crucial for 'refactoring' in the face of changing security priorities."
As you execute an iteration, you have daily stand-up meetings but you should also have continuous integration, making use of code scanning tools and security testing tools.
You should also adhere to common coding standards and security guidelines, Cornell said. "You should always be enforcing security standards, as they're crucial for communal code ownership," he said.
When closing an iteration, run automated customer acceptance tests but make sure to include negative testing for identified threats. You should also conduct a security code review, as something may have happened informally during pair programming, Cornell said.
During the final phase of stabilizing a release, you want to make one last push for security and test for defects and vulnerabilities. Prioritize vulnerabilities with client input based on agreed-upon STRIDE and DREAD standards. You also want to include traditional penetration testing.
"A penetration test is a confirmation that you've completed your security goals," Cornell said.
The biggest compromises made are that feature-focus iterations remove some "top-down" control and that more documentation is required than in a pure agile development.
"What you've added to the agile process is trustworthiness," Cornell said. "We didn't invent new security things to be done, but made them fit into the agile development life cycle."
In a world where applications are increasingly under attack, the challenge is to figure out what to do differently, he added.
"Security is not something typically taken into account from people talking about and writing about agile development," Cornell said. "What we need to do is bring back some of the security things."