By Nick Butler
Tags: Agile , Development
This guide shows you how to assure yourself that security risks are managed on Agile projects. You’ll find out how to lock security into Agile software development, and learn the practices and processes to put in place. It’ll also give you an idea of the things to look for and questions to ask when working with a new team.
The guide looks at:
The guide is for anyone who is leading, supporting or planning Agile software projects. It’s for project managers and sponsors, product owners or product managers, agile coaches or scrum masters.
It’s also for developers. Because security in Agile is tailored to the specifics of your project, team and technology stack, the guide focuses on what you do, not on the details of how you do it.
The key to security in Agile software development is having a team that is empowered to build security into their practices, processes and pipelines.
You can do this by creating a team culture of security and building security into your software development lifecycle.
“It’s about building security into each step as a quality factor,” says Boost’s Innovation Lead Andy Gray.
The main feature of Agile from a security point of view is that you deliver valuable, user-ready software in short iterations. Each iteration, you add improvements based on what you learned from the last. The process of regularly pushing these improvements out live to your users is called continuous delivery. The manual and automated steps you go through each time make up your continuous delivery pipeline.
Information security is what you do to minimise the risk that your people, systems or data will be used in ways that cause physical, financial or reputational harm. Because Agile is iterative, you need to build ways to minimise risk into each iteration and into your pipeline.
This is part of what is meant when the principles of Agile call for continuous attention to technical excellence.
Agile development helps make risks transparent. It’s easier to test working software than it is to assess risk in written requirements or unfinished work.
Coupled with this, Agile teams prioritise the simplest valuable changes. These small changes make it much easier to assess risks. As a rule of thumb, 10 times more code is 100 times more complex. And because you assess risk often, you get better at it. Moreover, you don’t build anything you don’t need. As a result, you don’t have to secure unused features or functionality.
In Agile, you empower developers to come up with solutions themselves. This creates motivated teams. It lets you harness their expertise to create security solutions that suit your specific systems and situations.
On top of this, continuous delivery sets you up to make rapid changes when new vulnerabilities are identified.
Security in Agile is about embracing change and making change safe.
Security risks are often summed up by the acronym CIA:
Managing risk is a prioritisation task. You want to find the interventions that most reduce both the likelihood and the impact of a security issue. You do this in the knowledge that you can never get the risk to zero.
In Agile, product leaders set the priorities, which provides an effective lever for managing security risk.
A good starting point for prioritisation, though it’s only a starting point, is the Open Web Application Security Project’s list of 10 top risks. These are based on data on what has caused the most security incidents.
To manage risk you need to understand it. You need to understand your potential threats and the attackers behind them. You need to understand your own vulnerability so you can prioritise effort. What is the likelihood of attack and what is the impact if one takes place?
Security in Agile starts with understanding threats both outside in and inside out.
Attack surface mapping helps identify your exposure to threats from the inside out. Threat modelling helps you identify your external threats. And threat intelligence keeps you on top of what’s happening now.
The standard way to understand your internal threats is to map your attack surface. What are the potential ways attackers can get in? This is normally broken into three parts:
A threat model is a picture of your software system. This picture shows its structure, the threats it faces, controls for these threats and how you’ll know these controls are working. Commonly this is a flow diagram that shows:
When we’re doing threat modelling at Boost, we’ve gone for Microsoft’s STRIDE approach. This gives a structured way to understand attackers. It breaks down threats and solutions into these categories:
Running a whiteboard session for the developers works well. It builds a shared understanding of the threat model and gets the benefits of everyone’s ideas. Plus the whiteboard keeps the information visible in your workspace.
Because Agile teams release regularly, your attack surface changes regularly. This means you need to find an efficient and pragmatic way to keep your threat model up to date. Focusing on those changes most likely to have security implications helps.
The threat landscape changes constantly, so you need to keep on top of what’s happening today. In the lingo of security, you need to gather threat intelligence.
There are a multitude of threat intelligence resources. Your team can focus on those that relate to your technology stack, along with those that cover general threats.
Additionally, your own monitoring and alerts show you what’s currently happening in your system. You can use this intel to identify priorities.
Let’s look at ways a team can be empowered to embed security in Agile development. How do you develop your security capability and practices?
Security capability:
Security practices:
Here is Agile principle 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Developers like to solve problems. You can take advantage of this by empowering them to treat security as a problem to solve as a team.
To do this you need a culture of team ownership, transparency and safety. That way the team can and will discuss and address security in an open and effective way.
“The project and how it’s run and how it’s built is everyone on the team’s responsibility,” says Andy. “Everyone on the team has ownership.”
Your team might formalise their shared responsibility. You can do this by specifically addressing security in your Definition of Done (your agreed standards of quality) and your Team Charter (your agreed way of working).
Having in-house security experts who can advise and coach the wider team works well. You can also take turns to wear the team’s security hat. Whoever’s wearing the hat keeps security top of mind in each meeting or activity. These might include things like discovery workshops, roadmap planning, iteration planning, daily stand-ups, reviews to demo your latest working software and retrospectives to look at how your team has been working together.
As noted, your people are part of your attack surface. That means that security awareness training is a good place to start.
At Boost, our training has included regular episodes of security awareness drama The Inside Man. The diabolical twists and turns of this show have provoked much consternation. We’re also using New Zealand online security trainers SafeStack Academy for security and privacy awareness training and secure development training.
In line with the Agile preference for face-to-face communication, much of our security training is personal, through onboarding, pairing and mentoring.
Because the team at Boost can choose their professional development, different developers have earned certification in different areas. Recently the cloud has been a focus, with a number of developers doing AWS (Amazon Web Services) and Kubernetes courses.
OWASP (the Open Web Application Security Project) has a number of tools and guides, and runs regular conferences. Here’s what Boost developer Katherine Nagels learned when she attended the 11th OWASP New Zealand Day.
In New Zealand, the government’s New Zealand Information Security Manual is a de facto standard. It gets pretty technical though.
Internationally, ISO/IEC 27001 is a family of information security management standards.
Getting external reviews and advice brings objectivity to your security assurance and gives you access to specialist skills.
At Boost, we’ve commissioned external reviews both for our own processes and systems, and for our clients’ applications. In both instances, we’ve gained valuable learnings in addition to the compliance and assurance benefits.
For new client projects or major releases, common security and privacy checks include:
Discovery in Agile is the ongoing process of learning the users’ needs and how best to meet them. When initiating projects, it’s worth starting with a discovery workshop. This helps you align your team behind a common vision of your goals, and the steps you need to take to get there.
These workshops are a good opportunity for the product leader to set priorities for security.
You’ll also want to let the development team know the different types of data your software will handle. For government agencies that will include classifications.
It’s also a chance to give the team a heads up about any external security reviews you’ll want to run.
In Agile, architectures emerge as you learn more about the best way to meet user needs. But you also have to make initial decisions in order to develop working software in your first iterations. These early decisions will pick from the range of secure architecture patterns.
At Boost for example, we’ve set up standard AWS authentication architectures that can be reused across each new project. This both speeds up the process and starts from a secure base.
Basing your work on some assumptions can help. Assume attackers know exactly how your system works. Assume that some part is compromised. In “zero trust networks”, no part of the system assumes that any other part is trustworthy.
User stories are the most common way of setting out requirements in Agile.
Keep security visible by highlighting security-specific stories (login or password recovery stories for example). You’ll also want to highlight any security implications in other stories. Consider the ops and infrastructure implications as well as functional requirements for these stories.
The OWASP Application Verification Standard (ASVS) can be useful when creating security stories. It’s designed for auditors but developers can use the ASVS checklists to make sure they handle security controls correctly.
Discuss the security implications of each story you’re refining or looking at bringing into the next iteration. This builds a shared understanding and gives the whole team a chance to contribute solutions.
The Agile drive for simplicity is an important ally in coding for security. Unnecessary complexity is the enemy. As cryptography expert Bruce Schneier puts it, “You can’t secure what you don’t understand.”
At Boost we mainly build our applications in Ruby, partly because the language favours clarity and self-documenting code. This makes ensuring security easier.
Writing the code is just the start. You also check that it’s secure through:
For the developers here at Boost, the code review is more than just a check. It’s part of our culture of shared ownership and a shared commitment to quality.
“It’s a “wisdom of many” approach,” says Andy.
As well as catching potential security issues, building code reviews into your processes has other benefits. It helps you make sure your approaches to security are consistent and understood across the team.
Agile makes code reviews easier because you’re always trying to make the smallest valuable changes. Small changes are easier to review.
Along with code reviews from peers, there are automatic static code analysis tools. These scan the code to identify security issues. They’re static because they don’t actually run the code. At Boost we use Brakeman for Rails. You use these in addition to, not instead of, peer code review.
You can set up your release pipeline so these tasks must be completed or put them in your Definition of Done (DoD).
To stop testing becoming a blocker, Agile teams tend to automate testing and go for Test Driven Development. In TDD, testing is built into the development process right from the start. You write failing tests before you write the code needed for the tests to pass.
In security circles, any bug is considered a security risk. That means robust automated tests are essential. Because you’ve highlighted security stories during iteration planning, you can give these greater scrutiny during testing.
As with code review, this can be mandated in your pipeline or in your DoD.
For new projects or big changes, you’ll often need to get external security testing too.
Agile pushes you to break down the divide between development and operations. It encourages a DevOps approach in which development and operations are all part of the same continuous pipeline.
This means developers need to know how to harden all aspects of their infrastructure so it’s secure. That includes the build pipeline, code repositories like GitHub and all servers, be they on-premises or in the cloud.
Automated system provisioning and configuration management tools like Docker help. That’s because they give you a consistent, traceable way to set up your environments securely.
As noted earlier, you’ll also monitor the system to gather threat intelligence.
Cloud services like AWS, Microsoft Azure and Google Cloud make it easy to run your applications in the cloud. It’s also easy to get security wrong if you don’t keep it top of mind as you go. Default settings, for example, are rarely secure.
Preparing for security incidents helps you reduce the impact should you ever have one. First, create a plan, then run exercises to check that your plan works. This lets you iron out wrinkles. It also makes it easier to put the plan into practice under the pressure of an actual event.
Andy says the Boost team have found that incident response simulations are valuable exercises.
“It helps us understand what our plan is and who should do what,” he says. Particularly useful, he says, is the idea that you separate what you do to contain the problem from understanding its root cause.
New vulnerabilities arise all the time. That means you need to scan your system regularly and fix any vulnerabilities rapidly. Again, the Agile approach encourages you to streamline and automate your scanning.
You can use your attack surface map and threat modelling to guide scanning. You want to make sure you cover vulnerabilities in all your dependencies and throughout your software supply chain.
Security in Agile software development is about embracing change. Rather than try to resist or control change, we set up our people and processes to make change safe.
Designing for security and privacy — a guide for NZ government agencies
Project risk management with Agile — a guide from Boost CEO Nathan Donaldson
Agile Application Security — book by Laura Bell, Michael Brunton-Spall, Rich Smith, Jim Bird
