The Agile development process focuses on user stories in order to build products. These stories are delivered in "sprints," which are intended to provide quick feedback. And while that quick feedback is important, the process behind it — which comprises whatever work is conducted during a sprint — comes with a major downside: constant architectural refactoring.
The analyst group Securosis provides a strong overview of process changes that need to occur when implementing a secure Agile development process. While that overview does outline some helpful modifications, there are two major challenges that organizations must face on their own: First, the changes that constant refactoring causes to a system's overall security; second, the inherent need to efficiently execute and provide results of any security testing within a sprint's short time frame.
Security within a system is kind of like character development in a book or film: The audience comes to understand a character's identity through the nuances and detailed actions that occur throughout, rather than through a portrayal that's built into one specific scene. A story cannot be completely written without keeping that identity in mind.
In a similar fashion, security controls rely on a complete picture of the application. It is important to include security in user stories and understand the impact of how failing to do so will alter security's identity within an entire application.
Developers or software engineers who are working on specific user stories face the challenge of understanding a system's overarching security. This is especially difficult when there are numerous components and integration points, as is now a trend among cloud-based systems. It is quite easy to lose sight of the required security for a given system when you're focused on one user story; as a result, a complete architecture risk assessment may be overlooked.
Security integrity requires a comprehensive review of controls, validation of design and rigorous testing. Sprints prevent a complete testing cycle, relying instead on automation. The trouble with automated testing lies in its ability to test use cases, since security testing often relies on components outside the current sprint. This leads to two challenges:
The Agile development process introduces the same challenges as any other software development life cycle when it comes to implementing a software security-assurance program; for example, obtaining support from upper management, changing the relationships between developers and security advisers and implementing new processes. And it can be difficult to maintain a holistic view of system security and ensure that automated security testing is comprehensive within a short time frame.
Much in the way a writer ensures that her characters are thoroughly developed, a program's owner ensures the security within an overall system. But tackling the challenges of process modification when you're incorporating security into Agile takes a team effort: It is up to everyone to ensure that each scene is built and executed as efficiently as possible.
Photo Source: Wikimedia Commons