Being truly ‘Secure-by-Design’

Introduction

Imagine developing a new mobile application for your company. Going through the entire development cycle of identifying functional and non-functional requirements, coding, and testing. And then in one of the post-development security tests (say, in a SAST scan), the scrum team ‘discovers’ that an important use-case has been left open to potential vulnerabilities, which leads to a major re-design (read ‘re-work’) of the application. Such a scenario is fairly common. In fact, traditionally, the application security domain has focused on “secure-by-test” approach by employing a plethora of scanning tools: Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and the latest Interactive Application Security Testing (IAST). While these tools are very important to detect potential security vulnerabilities in the application, it is important to adopt an approach which helps to prevent these vulnerabilities occurring in the first place.

So, let’s take a look at how we can make the transition to “secure-by-design” rather than “secure-by-test”!

Firstly, what does “secure-by-design” mean?

While “secure by design” can cover a host of aspects like governance, policies and enterprise security architecture tools, in this article we will specifically focus on how to implement the concept of ‘secure-by-design’ in the application security domain, with a focus on threat modelling.

Threat modeling is the core to the concept of secure by design. In my view, it is one of the best ways of assessing the security posture of applications. In this blog post, I will outline what threat modelling is, its benefits and an example of how to develop a threat model for an application.

What is threat modeling and its advantages?

Threat modeling is a structured approach to identify, quantify and address the security risks associated with an application. It ensures that applications are developed with in-built security right from the inception phase of SDLC.

Creating a threat model for an application during the design phase has several advantages:

• Threat(s) identification in the early stages of development lifecycle.
• The ability to clearly visualize and understand risk, including: some text
  • The possible attack vectors on an application and the data;
  • The risk level of each potential threat; and
  • Action that needs to be planned to remediate the threat.
• An increase in security awareness within the development teams.

Popular Threat Modeling Frameworks

A threat model can be created in multiple ways. There are many frameworks that have been developed over the years. The choice of framework depends on the focus of the project such as risk, security and privacy. Here are some of the popular frameworks used to create threat models:

1. STRIDE and its associated derivations

STRIDE (which stands for Spoofing, Tampering, Repudiation, Information disclosure (privacy breach or data leak), Denial of service and Elevation of privilege) was invented in 1999 and adopted by Microsoft in 2002. It is one of the most mature threat modeling methods. It has an open-source version and is widely adopted in the developer community.

More information on the STRIDE framework.

1. Attack Trees

One of the oldest ways and mostly widely applied techniques is using attack trees to model threats. Here the root of the tree are the goal of the attack and leaves are ways to achieve that goal. Each tree represents different goal.

More information on attack trees

1. PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat-modeling framework developed in 2012. It employs an attacker-centric perspective to produce an asset-centric output in the form of threat enumeration and scoring.

More information on the PASTA framework

1. LINDDUN

LIDDUN (Linkability, Identifiability, Nonrepudiation, Detectability, Disclosure of information, Unawareness, Noncompliance), focuses on privacy concerns and can be used for data security.

More information on LINDDUN framework

1. Persona non Grata (PnG)

PnG focuses emulates the behavior, motivation and skill of a human attacker. The idea is to introduce the potential attacker and their point of view.

More information on Persona non Grata framework

1. Security cards

Security cards are more of a brainstorming approach with the help of a deck of 42 cards to facilitate threat-discovery activities.

More information on security cards

And there are many other techniques…

No matter what tool you choose or approach you take, developing a threat model will generally involve the following steps:

Let’s dive into each of these steps and understand it in some detail.

Creating a STRIDE Threat Model

Let’s take the STRIDE threat modeling technique and emulate the steps involved in the process of creating a threat model as this is one of the most popular and mature threat models used.

The STRIDE technique provides classification of threats in six categories.

‍

‍

For this blog, I will use the ‘Microsoft Threat Modeling Tool’ as an example, since this is the one of the oldest and most tested open-source threat modeling tools in the market. It is based on the STRIDE technique and uses the standard notation for visualizing components, data flows, and security boundaries.

Download the Microsoft Threat Modeling Tool

As an example, lets create a threat model for a school with the requirement that students and staff can login remotely and access their workstations. Student gain access through a VPN and staff log in from a dedicated browser interface. The internal financial application is in a separate network segment, accessible to only authorised individuals.

‍

Step 1: Identify components

A draft model that identifies components is often developed during the solution design phase during a brainstorming session between the security architects, senior developers and project manager (and other relevant stakeholders).

Symbols used in creating a threat model in STRIDE:

1. Start by identifying the most interesting elements of the solution

• Assets, entry and exit points

In our example the various entities would be:

2. Identify the Trust Boundaries

3. Identify all process flows between the various elements

• Identify all the data flows and data-stores where the data will finally reside.

4. Enumerate assumptions and dependencies

5. Create a high level Data Flow Diagram (DFD), after detailed discussion about the above entities.

‍

Step 2: Identify threats

Once a high-level DFD is created, the Microsoft Threat Modeling Tool can be used to provide a detailed report on ALL POSSIBLE threats whether mitigated or not.

The report should be analysed with security architects, senior developers and relevant stakeholders.

Some of the possible threat scenarios are as follows:

‍

Step 3: Address threats

The identified threats can be dealt with in different ways based on the risk appetite of the organisation. Possible ways to address the identified threats include:

1. Take no action
2. Inform stakeholders about the risk (potentially in combination with other actions)
3. Mitigate the risk
4. Accept the risk
5. Transfer the risk
6. Eliminate the risk

Step 4: Validate

Once a detailed analysis of all the threats has been done and list of threats to be mitigated has been identified, the development/validation teams can validate the threats in different ways during the various phases of SDLC. The developers perform code reviews and, once the code is ready, testers develop specific tests to check if the application code addresses the threats identified.

Let’s see this in bit more detail:

Code Review

Code review can be done in either as a peer-review or by scanning the application source code for security vulnerabilities. As mentioned earlier, there are various application scanning tools (SAST/IAST) which can be used for this purpose. If the application code addresses the threats identified earlier, the scanning tools will not highlight them as vulnerabilities.

Test Planning

Test planning should ensure that the list of threats is used as a base for test planning. It’s important to ensure that tests cover all the possible scenarios highlighted in the threat model.

Penetration Testing

Penetration Testing is a manual testing process in which pen testers simulate the attack against the application in real time. The threats identified during the design phase act as the input for this process.

Conclusion

A true shift-left in application security is achieved by adopting threat modelling as a necessary step early in the SDLC. This is crucial for critical applications that handle the core business requirements of an organization, for instance financial/critical transactions, confidential data etc. It is important to carefully select the threat modelling tool and this choice is influenced by the threat modelling framework which the organization wants to focus on. During the design and planning phase, threat modelling encourages defence-in-depth and structurally sound security controls. A high-level threat model should be applied while designing the application and refined throughout the lifecycle. This helps the team to address the threats continuously while the project is ongoing.