Posted by David Johansson on May 5, 2016
Security, including software security, is very much rooted in a control culture. Security concepts such as firewall rules, access controls, and input validation are all about getting and keeping control—we frequently refer to these as security controls. Standardized processes that promote stability and order are also highly valued components of security. This control culture often causes friction when security is introduced in Agile development teams that have a very different culture.
Agile software development is more about culture than a set of processes, although it is often mistaken for the processes it is associated with (e.g., Scrum). The values and beliefs that define the idea of Agile are described in the Agile Manifesto. This manifesto does not define a specific development process, but rather the values and priorities that underpin Agile software development.
In Michael Sahota’s book An Agile Adoption and Transformation Survival Guide, the difficulties of adopting Agile in a company culture that isn’t aligned with the Agile culture of collaboration and cultivation is explored. One particularly interesting detail is that imposing Agile principles in a control culture often fails due to the different, and sometimes opposing, mindsets in these cultures. Likewise, I believe that imposing traditional software security processes rooted in the control culture on a development team upholding values aligned with the Agile Manifesto runs the risk of failure due to this culture clash.
Continuing with the idea that Agile is more of a culture than a process, the idea of “fixing security” by just imposing a security process is bound to fail. Instead, a change of mindset regarding security is necessary. Adjust security activities to align with the values of the Agile culture, and ensure that they work together, not against, the existing processes and tools used by the development team.
For example, mandating that all software must undergo an extensive penetration test by an external security team before release will not work well for a team delivering frequent releases of working software, as this time-consuming control gate would work against their culture and stop their productivity. Instead, security experts should collaborate in partnership with the team during their software development, helping to cultivate a mindset where security becomes a natural part of developers’ daily job and provide the necessary tools for supporting this effort. It is imperative that these tools work with the team’s existing toolchain and can be aligned with their way of work without too much disruption.
Those of us who work in the security field tend to sometimes forget why we’re concerned with security in the first place. For many of us, security has become such a central part of our work that we almost automatically try to “secure” things to the highest level possible, without evaluating the need of this effort or possible side effects.
To give you an example, I recall investigating a strange issue that was preventing me from printing pages from HTTPS sites in my web browser, only to find out that it was due to me hardening the browser to such an extent that it didn’t allow saving the temporary print spooling file to disk. In my effort to secure the system, I went too far without considering the impact. To make the system usable again, I had to take a step back to find the right balance. After all, security is not the end-goal in and of itself.
[tweetthis remove_hidden_hashtags=”true”]There’s an important difference between being #Agile and doing Agile. Here’s why:[/tweetthis]
The purpose of any security effort must be to manage business risk with the aim of reducing risk to an acceptable level. Over-ambitious and time-consuming security efforts that collide with the development culture may in fact be counterproductive if they impede the business. For some companies, a slow-down in development throughput, leading to a delay in time-to-market, may be considered one of their biggest business risks. This means that complex, process-heavy security initiatives invariably run the risk of being abandoned by the team as soon as it slows down the throughput too much.
On the other hand, a security breach resulting from a company’s negligence of security can also have devastating effects on a company’s productivity and in the worst cases can even put them out of business.
To paraphrase John Ray and William C. Ray, incorporating security into Agile teams is an ongoing series of trade-offs between making the development process productive enough to get done what the business wants to achieve, and secure enough to retain productivity. Any software security initiative introduced to an Agile and fast-moving development team must take this into consideration.