Most IT companies today are using an Agile approach to software development. Based on the Agile Manifesto from 2001, this methodology is in many ways the exact opposite of the waterfall method which it superseded. Small teams working in unison to provide fast and incremental product improvements is what Agile is all about. This allows for a lot of flexibility to make rapid changes and fix issues as they appear. Agile provides higher customer confidence, as well as an ability to adapt quickly to changing requirements.
Another advantage of fixing issues in bite sized-increments is that it allows for improved planning and faster and more reliable testing. The Agile manifesto pledges to provide users with what they want almost instantly while saving on development time, resources and overhead. However, Agile teams often overlook security during the development process. What’s more, the manifesto does not explicitly mention any security best practices. Every digital product or service is only as good as its security, and Agile teams need to be aware of this.
Why Agile and Security Don’t Always Get Along
Security procedures and methodologies are sometimes thought to add a systematic and rigid approach to development. In contrast, Agile development values quickly responding to a change over planning security. It is no wonder that a rift can surface between agile and security. When a system is unpredictable, it is a lot harder to secure since continuous software releases and frequent feature changes can create security risks. There are two main reasons why security often gets the short end of the stick.
Reason #1
The first is that agile views security as a non-functional requirement, or NFR. In other words, it is not associated with extending features and the functional parts of the system. User stories are the backbone of the Agile approach, and security related NFRs usually receive the least amount of attention. Business requirements are written out as stories so that developers know what the code should accomplish and how it should work.
An example of a user story would be “As a logged in user, I have access to all of my data through my web application”. The whole team then uses these stories as blueprints and guides for development and planning. Security stories work in the other direction. A good user story negates unwanted actions or conditions that threaten proper and secure functioning of the application. The absence of well-written security user stories leads to gaps in security planning and implementation.
Reason #2
The second reason why Agile enterprises run into security difficulties is their continued use of security tools and methodologies that are not Agile-ready. In traditional waterfall methods, the development phase does not address security concerns. Security planning is carried out at the start of the project, and security testing is conducted at the end. This approach to security is deficient in many ways but especially so for Agile. The high speed of feature releases and the inter-dependencies between many small teams means that security testing cannot wait. Testing needs to be continuous and integrated into the entire software life cycle. For this to happen security processes need to be synchronized with business requirements. The following is a list of ways you can integrate security into your agile process.
Security User Stories
The first step to a secure development process is to work on writing thorough security-based user stories. Security and development teams need to work together to create functional, applicable and clear user stories for every security requirement. The next step is to break down the stories into sub-tasks and define when the tasks should be run. This will not only protect your product and users but also put your team in a security-first mindset.
When planning security stories and tasks it helps to put yourself in the shoes of a would-be hacker. The best way of doing this is to write so-called “evil user stories” for every new sprint. By thinking like a hacker, you can improve input validation, data protection, session management, data encryption and much more. OWSAP (Open Source Foundation for Application Security) provides some great examples of evil user stories that are well worth implementing.
Make Developers Responsible for Secure Development
One of the most effective ways to make your Agile development process secure is for developers to share in security responsibilities. Just leaving security to the security experts does not scale, so every team member should be part of the security solution. Security education needs to be high on the list of every developer’s learning curve. Having your developers champion security adoption and implementation is a practical move as well, especially when you consider that they far outnumber security team members.
While the security team needs to drive the planning and final testing phases, programmers need to take the lead during development. This includes frequent security scans and continuous fixes and improvements. Implementing security early on in the SDLC will minimize the risk of large security issues.
Keep Security Agile
The IT landscape is constantly growing and evolving, as are the security risks. To stay on top of things, it is crucial to adapt, iterate and grow your security efforts. A core principle of Agile development is to continuously change and adapt to better fit the needs of dev teams, users and clients. If software development moves faster than the security processes, this leaves room for vulnerabilities.
In keeping with this, security user stories need to be treated just like any other Agile stories. Developers and security experts need to continuously revise and change security stories to adapt to current needs and evolving requirements. Every introduction of new development tools and processes needs to be covered by the appropriate security tasks.
There are several security tools on the market that allow developers to carry out effortless static code analysis. The dev team should use these tools to catch security vulnerabilities early. Fixing a security issue early in the life cycle is exponentially cheaper than fixing it after development, or even worse in production.
