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.
You can follow Michael on Twitter, sign up now for email updates from this blog or subscribe to the feed.
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.
4 comments
Comment by andyjpb posted on
How do the "non-functional" requirements of security fit into the functionality driven sprints of an agile workflow?
Non-functional things such as performance, security and architectural modularity often become second class citizens when users are demanding features and the backlog is large.
Comment by Michael Brunton-Spall posted on
Hey Andy,
This is indeed a problem in some organisations. If the product owner sees the system only through the lens of features delivered, then yes, certain attributes, such as security, speed and responsiveness can be deprioritised in favour of delivering features.
A good product manager or service manager understands that what we used to call non-functional requirements are in fact entirely functional requirements, which provide concrete benefits and advantages and they should be prioritised appropriately. How you make the decision makers understand that and actually do it is through good governance structures that ensure the service manager or owner governs with these in mind, rather than just through features delivered.
Comment by gsc034 posted on
As with most things GDS, this article was written by someone who obviously has never been involved with real-world considerations (as opposed to the standard GDS naive panacea view). Security management within application development, third-party outsourcing, etc. is a critical function, not a nice to have. Users may want you to introduce thousands of new features each day/week/sprint but the implications of doing so are often ignored by those ignorant of the actual threat and reality of the digital age today. Security debt is a convenient means of ignoring your responsibility to protect your users; if the real world of business acted in the way advocated by the amateurs within GDS then it would be in a considerably worse situation than it already is. Digital by default implies secure by default - and that is something that takes actual knowledge and expertise of the threat to implement, not an afterthought in a product backlog.
Comment by Michael Brunton-Spall posted on
Hey gsc034,
Those are some good points, and I think entirely in line with what we are advocating in this talk and blog post. I encourage you to take the 45 minutes to watch the video as well as read this post.
As I outlined in the talk and in the blog above, one of the critical parts of making this process work is ensuring the entire team, including the decision makers and product owners, are educated about the threats and risks to the service. Whether you do that through producing attack trees, threat modelling, simulating attacks, providing threat briefs or other mechanisms, it's critical the entire team is involved.
If you can achieve that, developers and product owners will discuss the relative risks of a given implementation without needing to get "security" involved. Of course, if they aren't sure of the implications, or need more details, they may call for an expert opinion. Mostly though, we see teams owning the security of the service and wanting to provide the most secure system as possible.
The concept of security debt is used, as a metaphor in Agile to indicate that debt needs repaying and incurs interest while it isn't paid off. In old traditional systems, ‘security debt’ was commonly labelled as residual risk, improvement matrices or sometimes P3 or P4 issues.
In my talks, I often use the example of 2-factor authentication when discussing security debt. Your threat model may include attackers stealing credentials and re-using them. A good control to mitigate this threat (but not totally nullify it) is to add a second factor of authentication to the system. However, when building a system, you have a variety of things to do, and adding 2-factor authentication using TOTP might not mitigate as much risk as the value of spending time on other features or security controls. Therefore, you decide, as a team, to run the risk of credentials possibly being stolen, while you implement other features, and later come back to implement 2-factor controls.
In traditional risk terms, you've gone with an accepted residual risk that is within the organisation's risk appetite. You've chosen to accept the risk rather than transfer, mitigate or avoid the risk. When I talk about this, I often say the product manager has the choice to disable the feature, thus avoiding the risk, mitigating the risk using a control, or accepting the risk (temporarily hopefully).
One of the advantages of our model, of iteratively building the system, is that it is far easier to build an understanding of what risks you have accepted, and to maintain a running live risk log. This means you might only accept a risk for a short time, or at least be consciously aware of the risks, so that you can react to changing threat models.
By ensuring that product owners and the decision makers and implementers are working together and taking sensible security decisions, based on an understanding of the threat model and the risks involved, we see far better security decisions being made earlier, being made contextually, and being made appropriately.
We find this is better than when an implementation team document their decisions for the assurance team, and then claim they've run out of budget to implement all the requirements from security so late in the process.