How to Integrate Security Analysis in Agile Software Development

Code reviews have long been an integral part of the development process, but significantly less often is a security analysis included as an integral part of the development in a project. Often, security is omitted until the end of a project, where attempts are made to patch things up by, for example, setting up a firewall. This is rarely enough to make the system secure. At the same time, since May 25, 2018, companies have had an additional responsibility for users’ data in the form of GDPR*.

But then it must be good enough to consider security at the start of the project and then conduct a final security analysis at the end of the process, right?

The answer is, in principle, yes, but it presents some challenges:

• Projects tend to change along the way, so assumptions made at the start may no longer hold.
• You cannot think of all security details at the start of a project.
• Even if you catch all security flaws in the final analysis, it will be more expensive and time-consuming to fix the flaws than if you had found and mitigated them during the project. 
• If flaws are only discovered in the final analysis, it can lead to decisions to accept risks that could otherwise have been avoided.
• It can be expensive to conduct a large upfront analysis, which may result in no funds being left to implement the identified problems.

One solution is to include security analysis more frequently and optimally as an integrated part of the development process. This can be done in several ways. For example, by having a dedicated security expert on the project who ensures the process and continuously conducts code reviews. However, this is not always possible – either because the project does not have the budget for it or because the number of security experts is limited.

You can also divide the final analysis into smaller parts along the way and summarize at the end. Another approach can be to use what Jim Gumbley describes as agile threat modelling, which naturally fits into the Scrum methodology’s sprints. This is the approach we focus on here.

Why is security important at all?

In these modern times, your company will often use some more or less intelligent IT in connection with performing a piece of work. It could be a computer, an IoT device, an intelligent combine harvester, etc. It is likely connected to the internet, and even if it is not, the code that constitutes the circuit in, for example, the combine harvester has probably been available via the internet at some point.

It could be that a competitor wants to put you out of business. It could be that an organization wants to use your IoT device as part of a botnet. Maybe it is just someone playing with hacking and using you as a playground. If you have many users, you could be a stepping stone to get hold of users’ passwords, which they have probably reused elsewhere. So even if you do not think you have interesting data, it may very well be the case.

The point is: If you own something of value, it can be worth attacking.

Agile Threat Modelling

Agile threat modelling is a framework that aims to enable the execution of a security analysis in a relatively short time by utilizing a predefined scope for each session, ensuring the necessary focus.

Threat modeling may sound fancy and difficult, but it is essentially about finding vulnerabilities in your system based on a model that shows the system without introducing unnecessary complexity. The agile aspect consists of limiting oneself to smaller parts of the system and possibly reviewing the same part multiple times during the project if that part changes enough.

Agile threat modelling aims to enable the average developer to consider security in any system.

Execution of threat modelling

When performing threat modeling, you should at a minimum ask yourself these three questions:

1. What are we building?
2. What can go wrong?
3. What should we do about it?

The following sections will provide ideas on how the different aspects of these questions can be addressed.

Scope

Regardless of the approach used, you should consider what scope you use for your analysis. Your scope defines the framework for the analysis and thus also what you should not analyze. Without a defined scope, it is easy to try to consider all the attacks the world can throw at you. This often results in losing details and not delving into technical problems.

Once you agree on the scope of the analysis, you can begin. Try to frame a scope that matches the feature or epic that the next sprint will focus on.

Do not forget to use a more high-level scope occasionally to catch potential problems in the system that may only be discovered by looking at the architecture more abstractly.

Outcome

The result of the analysis should be a series of points that potentially need to be added to the backlog. This can be done either practically with a series of post-its or by entering them into an issue tracking system such as Jira. Regardless, there should be a decision-maker who determines which mitigation strategies should be added to the backlog and which security issues to accept the risk of.

Who should Perform the Threat Modelling?

The classic approach is for a security expert to perform the analysis with the help of selected individuals who know the system well from the necessary perspectives for the analysis.

In this agile approach, we will turn it around a bit and argue that the security expert is not a critical resource but just another facet of the analysis. We suggest including as many roles as practically possible. This ensures the spread of knowledge to the entire team and specifically to decision-makers, who will gain a better understanding of why the identified problems are important to address. Therefore, remember to include non-technical roles in the analysis work.

What are we building?

Low-level architecture drawing

Start by drawing the systems that interact with each other on a whiteboard. Also, draw all data flows as defined by the scope and the people involved. It could look like Figure 1. Here, the red arrows are data flows, green is the division of authorization boundaries, and blue are relevant assets for the given scope.

Assets

Next, identify the assets that may be relevant to the scope and that the data flows affect. An asset is something important to the company using the product. This can include data (sensitive personal data, system-critical data, key material, etc.), involved persons (biometric login), or physical objects such as USB keys.

What can go wrong?

Attacks

Now for the fun part! Put yourself in the attacker’s shoes and try to find as many vulnerabilities in the system as the timeframe allows.

Focus on the technical issues.

To ensure we do not go down a rabbit hole, we suggest focusing only on technical issues rather than trying to protect against large organizations or intelligence agencies. This will likely quickly lead to the conclusion that no system is secure enough, and we might as well give up in advance.

Instead, think a bit cynically: We just need to make sure we are difficult enough to attack so that others are easier targets.

If you need inspiration, ask your security expert if they are present. Otherwise, you can use the following options:

• Focus on the asset that matters most and follow data flows to where an attacker might be in the system.
• Use the CIA approach (Confidentiality, Integrity, and Availability). Consider each of the three and how attacks can be carried out if one of the three is not present.
• Use STRIDE and review the system for each category of threats.
• Find inspiration in OWASP’s top ten or their cheat sheets.
• Think outside the box. For example, there may be a data flow you have not drawn.

Note each possible attack in a brainstorming style and move on to the next potential attack.

When you run out of possible attacks, use a risk assessment methodology to determine the extent of the attack. We suggest taking inspiration from OWASP’s risk rating methodology. Here, each attack is given an overall score from 0-9 in terms of likelihood and impact, which together determine the extent of the attack.

Find the method that works best for you, so it does not take too long, but where you still consider all the important factors. A few examples of attacks based on Figure 1 could be:

• The database does not use encryption at rest, and credentials for the external system can therefore be read if access to the database is forced.
• The connection from the Angular App to the backend only uses HTTP, which allows the JWT to be stolen and the user to be impersonated by an attacker.

What should we do about it?

Mitigation

Last but not least, we need to find ways to prevent the attacks. Consider how to defend against them and preferably consider several different ways. The project will likely want the cheapest solution, but make it clear if some solutions have shortcomings. Also, consider whether the solution creates new vulnerabilities.

Make these solutions available to the decision-maker and ensure they have all the prerequisites to make the right choices. There is no problem in not fixing all vulnerabilities as long as the decision is made with open eyes.