Agile showed a great way of building projects in an iterative fashion. Benefits of using Agile processes over waterfalls are evident.
However, even though agile projects have existed for years, the approach to security on these projects has remained the same as waterfall. Security testing / penetration testing is still big bang, just a week before release of the project.
There are some fundamental problems with the existing “waterfallish” approach to application security. Some of them are:
- Penetration testing very close to release, leads the developers and business finding workarounds for the vulnerabilities in a rush instead of patching them properly. This often leads to multiple unpatched vulnerabilities in long run. Also, there is a possibility of the workaround for one vulnerability making another component vulnerable.
- Sometimes security problems are result of the architectural decisions. For example, sending the current user password in plain text for “Forgot password” functionality. By the time these security vulnerabilities are uncovered, it might be too late to change the architecture.
- If the components / dependencies used (for example, libraries) have known vulnerabilities, it might be difficult to change them just before the project release.
Problems such as the ones mentioned above poses a very important question. What would it take to do application security the “agile way”?
In order to answer this question, the following points seemed imperative.
Developers who knows how to write “secure code”
Most of the security problems would be avoided if developers know and write secure code. Every time developers write code to accept user input, they should think about validation. Every time they needs to store customer data into database, they should think about the sensitivity of the data and the need of encryption.
Knowing about OWASP Top 10 vulnerabilities is a must. And then there are some great resources for developers to learn about secure coding practices. My favorites are:
- OWASP Secure Coding Practices – Quick Reference Guide
- Microsoft’s guide on writing secure code
- CERT Top 10 Secure Coding Practices
“Security expert” on the project
Let’s agree that no matter how much a developer tries to learn about secure coding practices, there will always be something in the code which only an experienced eyes can catch. Hence, it is advisable for each team to have at least one designated security expert who is reasonably experienced in the field of application security. The required experience level can vary based on the complexity and the number and type of “sensitive points” of the system, but the more experienced the security expert, the better.
Usually the role of security expert includes:
- Pairing with other developers on developing security sensitive stories.
- Uncovering and conveying different ways to break the system to the developers. This also means fixing the problems before the code is even checked-in into version control system.
- Taking part in the discussions on choosing libraries to use, deciding contracts with external systems, deciding public APIs, etc.
- Helping Quality Analysts to test security sensitive stories.
In addition to these tasks, the security expert is also expected to help in building secure code writing practices and security testing capabilities with the team.
“Security Sensitive” stories
In Iteration Planning Meeting, at the beginning of the each iteration, security expert (with the team) should mark stories involving security related design and decisions as “security sensitive”. Some sample scenarios in a story that must be marked as security sensitive are:
- Introducing a new user input field (text, dropdown, etc.)
- Storing user input to database
- Invoking external processes or system commands
- Processing data received from external system
- Dealing with authentication and authorization process
Abuse cases for each security sensitive story
Every story has acceptance criteria. For security sensitive stories Business Analyst (with the help of security expert) should write acceptance criteria from security point of view. Similar to Use Cases, Security expert is expected to write abuse cases around the functionality. This ultimately helps Quality Analysts to write test cases from security testing point of view.
Security testing before a story is “accepted by business”
When a security sensitive story moves to “in testing”, Quality Analysts must test the story for abuse cases to check expected system behavior. Security specialist can help Quality Analyst in this. Of course, this testing has to be done along with functional testing of the story. If a vulnerability is found during the testing, the story must be moved back to “ready for development”. Then developer fixes the vulnerability properly and moves the story again in the “ready for testing” lane. And the cycle continues. Once story is tested for all the functionality and no vulnerability and loss of functionality is reported, the story can be moved to “accepted by business” status.
Automation or no automation?
Automation of security testing is a very controversial point of discussion in the field of security. Some believe there is no replacement for human testing, whereas some believe there should be a full automation for testing.
I personally believe that there is a middle ground. Of course we need a security tester to find the vulnerabilities in the system. But once found, security testers should write automated test so that they will never need to test for the same vulnerability again in the same part of the system. Tools like OWASP Zed Attack Proxy can be helpful in writing such automated tests.
Conclusion
It goes without saying that we should build security into the application than around the application. Using the pointers above, we were able to successfully deliver relatively more secure system. We did have a “conventional” big bang penetration testing just before the project went live. But as expected, we did not have any high (or even medium) priority vulnerabilities reported in the system.
From the customer’s point of view, this process gave them a high confidence in the security of the system. A major point to note was that, there was no deadline slippage because of the security issues.
Finally, there is no silver bullet which can be applied to all projects. The whole point of being agile is that, it gives us opportunity to change or modify the approach which is best suited for the system under development. This post can be considered as a pointer on what is the minimum we can do in to bake security into the system being developed in agile way.
