Traditional security processes and ‘security says no’ can often seem to block progress in agile environments but there are ways to build software securely without compromising agility. It’s all about ensuring security is built into your development best practices so that everyone can build securely without having to be an expert.
Trusting your team
Security teams in agile environment can’t review every codebase change even if they want to. Work and deployments happen too quickly and too often so it’s just not feasible for them to review everything.
Instead, security experts can encourage and trust members of a development team to follow good security principles. The Government Digital Service contributed to CESG’s 3 sets of security guidelines for all teams to follow. The guidelines cover how to:
As well as putting trust in delivery teams to follow security guidelines, security teams need to change how they view their role. Security shouldn’t be the department that ‘says no’, it should be the department that makes building software easier. Security teams should aim to increase transparency of security threats, create simple systems and reduce security debt.
Increasing transparency of security threats
In existing systems, delivery teams can’t view some threat reports or system information because it’s sufficiently classified. That’s not good enough. All risks should be documented in a risk log that can be viewed by the project team at any time.
Creating simple systems
Systems that are simpler are easier to understand and secure. It’s the role of security teams to make it easy for product teams to choose the secure option. For example, security teams can provide libraries for identification or authentication, or patterns on how to configure software.
Reducing security debt
Agile teams need to move fast and sometimes this means not immediately addressing a security concern. This leads to a build up of ‘security debt’, which needs to be paid back in later iterations. Security teams can address this debt by putting stories into the product teams’ development pipeline, or adding acceptance criteria to current development stories. This requires close collaboration between the product team and security experts.
The other option would be to have a team entirely focussed on security debt but this can obstruct the pace of the product team (they may be forced to wait for a security iteration before they make their release).
DevOps makes security easier
The growth of DevOps has made operational security much easier. We treat infrastructure as code where possible. This gives us much more agility to quickly react to emerging threats in a security context. It means we can trace every change to a system and quickly see when and why changes were made.
We also automate tests so we have constant validation that everything in a system does what it should. We can then make fast patches to a system and have confidence they work.
Deployments in an agile team are regular and expected so it isn’t a major issue if we need to deploy urgent security patches. Who do you trust in an emergency, the person who has done a deployment 6 times in their life, or someone who has deployed 20 times this week?
Agile and security go hand in hand
Done well, agile development and operations go hand in hand with secure systems.
Security teams often rely on speed and transparency and this means involving many members of a development team in the response to threats. Agile is also built on the same principles of collaboration and responding to change. With a change of mindset, there’s no reason why security should be seen as a blocker to agile development.
The Australian Signals Directorate has produced a document that says 85% of cyber intrusions on government systems could be avoided by using an application allow list, patching and minimising application controls. Through following the advice above, you’ll be doing all these things.
You’ll be using testing tools to ensure your servers only run the applications they need to and you’ll be patching regularly as you make frequent iterations. The majority of system administrators are logged into their server admin account while also browsing the web and checking emails, leaving themselves open to attacks. But when working in an agile, Dev Ops environment, system administrators will rarely be logged into servers, instead pushing code and telling automated tools to do deployments.
This post is a summary of my full presentation on agile security at the GOTO 2016 conference.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.