A Few Steps To Conduct Threat Modelling in Serverless Applications

Build robust apps

My previous article discussed the benefits of threat modeling while developing serverless applications. In this article, I will explain the process of conducting threat modeling and documenting the threats, attackers, and mitigation steps.

STRIDE

As I briefly mentioned in my previous article, STRIDE is a widely used methodology in threat modeling. The process I will explain here is based on STRIDE, which stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Spoofing

Spoofing is pretending to be someone or something other than the original self.

• Spoofing a person

• Spoofing a role

• Spoofing a machine

• Spoofing a process

• Spoofing a file or data entity

Tampering

Tampering is modifying data on different media and platforms.

• Tampering a file on a disk, server, etc.

• Tampering the data flowing over a network

• Tampering the data in memory, injecting malicious execution

Repudiation

Repudiation is claiming you didn’t do something or arguing you were not responsible for what happened. It can be challenging because people can repudiate honestly or deceptively.

Repudiation disputes can be hard to prove without evidence in detailed system logs and execution traces.

Information disclosure

Information disclosure is about allowing people to see the information they are not authorized to see.

• Information disclosure against data stores, files, and archives

• Information disclosure against data in a workflow and network

• Information disclosure against a system process

Denial of service

Denial of service (DoS) attacks soak up or overwhelm a resource needed to provide service to end-users.

• DoS against an API

• DoS against a datastore

• DoS against a process

• DoS against a network

Elevation of privilege

Elevation of privilege is an attacker gaining permission to do something they are not authorized to do.

• Elevation through incorrect authorization checks

• Elevation through tampering data

• Elevation by corrupting a process

High-level mitigation plan

Source: Threat Modeling: Designing for Security

Sample Serverless Architecture

As a reference, we will use the following simple serverless architecture of an Order History Viewer application.

Serverless architecture. Image by the author.

The main elements of this architecture include:

• A browser frontend to interact with the service

• A backend-for-frontend (BFF) layer

• API Gateway endpoint for the service

• A lambda function to process the requests

• Datastores (DynamoDB) for orders and payments

• CloudWatch for metrics and logs

• Third-party application for monitoring and observability

Let’s now focus on the threat modeling process. Typically, it goes through three stages:

1. Collecting input for the process

2. The process itself

3. Compiling the outcome of the process

Input to Threat Modelling

The input details that feed to this process vary. The business domain, the complexity of the application, its target users, demography, the social status of the organization, and others can be part of this.

• The high-level architecture of the application

• Solution design details

• Dataflow diagrams

• Domain-specific industry compliance standards

• Operational requirements and constraints

• Security needs

• Trust Boundary

• Third-party vendors and partner applications

The list can be long for a complex serverless application but minimal for a simple service.

Process of Threat Modelling

The process can be a simple one-person activity or a brainstorming session involving many. The size and complexity of the serverless application influence this decision.

Process Lead

This is the moderator of the process. Their responsibilities include:

• Identifying and collecting the required input items

• Planning and conducting the threat modeling process

• Producing the outcome, which is the threat modeling document

One-person process

If the application is simple, compact, and self-explanatory, then it’s just the process lead’s task to produce the process document. This person may consult with others but otherwise works independently.

Brainstorming session

Engineers, architects, product owners, and business stakeholders gather to discuss and identify potential threats to the application. The process lead explains the architecture, data flows, and other notable points related to the application.

Everyone is encouraged to bring out all types of threats—not necessarily in any specific order. Threats are then grouped according to the STRIDE classification before being added to the threat modeling document.

The Outcome of Threat Modeling

A successful modeling exercise produces a detailed document that captures potential threats, severity, mitigation ideas, and the corresponding actions.

Threat modeling document content

Here are the most common sections of a threat modeling document. There is no reason why it should be limited to these. Add or alter sections that add value depending on your domain and requirements.

1. Description

2. Architecture

3. Dataflow diagram

4. Assets

5. Attackers

6. Exclusions

7. Requirements

8. Threats

9. Actions

10. Residual risks

1. Description

This section sets the context of the document. It summarizes the application and its characteristics.

Reference example: The Order History Viewer lets customers view their current and past order details. It also shows a summary of each order's payment details. This service is available to customers who have an account with the business.

2. Architecture

Add references and links to the application's architectural diagrams. This section is mainly for completeness and to provide context to the flow diagram below.

3. Dataflow diagram (DFD)

DFDs are common in threat modeling. They depict the data flow with simple elements such as:

• Process

• Data flow

• Datastore

• External entity

Though not necessary, colors can add clarity to threat modeling. Green represents a trusted zone, red represents untrusted, and blue represents the application.

Reference example:

Threat Model DFD. Image by the author.

4. Assets

In threat modeling, an asset is something of value.

• Things attackers want — These are mainly tangible items—payment details and business secrets.

• Things you want to protect — These are unquantifiable items. For example, you want to protect your company’s reputation.

• Stepping stones to the above — Compromised assets that lead to other assets. For example, once an attacker gains access to your laptop, they can then get hold of the company’s medical formulae stored in that device.

As part of the exercise, identify and list the assets with the following details:

• Name of the asset

• Description

• Location: if it is stored somewhere

• Criticality level (or confidentiality level)

Reference example:

Assets

5. Attackers

Identifying your application's attackers may seem like an easy task, but it can become challenging as you build the list. Your competitors, data miners, spies, terrorists, organized criminals, thieves, employees, etc., can all be attackers.

A good starting point is to have them grouped under two categories:

• External attackers — Attackers who have access to the internet. If you work with third-party applications and share APIs, build systems, logs, and data, then your eternal attackers may also originate from here.

• Internal attackers — A disgruntled employee, an untrustworthy admin user, an undercover employee working for a competitor, and even an innocent colleague who inadvertently shares details on social media can all be internal threats.

Reference example:

Attackers

6. Exclusions

This section identifies items beyond your threat model's scope and coverage.

Reference example:

Exclusions

7. Requirements

This is an important part of threat modeling. The requirements captured here serve as a cookbook to identify threats and lead to mitigation plans. Hence, it is often called the interplay between requirements, threats, and mitigations.

Source: Threat Modeling: Designing for Security

Different requirements originate from many parts of an organization, including the industry sector, platform, technology used, customers, etc.

• Business requirements include reputation-related requirements, measures to differ from competitors’ security practices, etc.

• Industry requirements—Details specific to the industry where the application will be launched. Examples include the medical industry, government organizations, and banking and financial sectors.

• Technology requirements—Elements such as your cloud platform and indirect factors such as third-party SaaS applications can create different security requirements.

• Compliance requirements—The Payment Card Industry Data Security Standard (PCI-DSS), The Health Insurance Portability and Accountability Act (HIPAA), and other regulatory bodies require several measures to consider when building a secure application.

• Privacy requirements — These include the protection of personal data, consent management, and more.

Reference example:

• Malicious account holders should not intercept and impersonate the service.

• Internal employees should not be able to access payment data.

• Sensitive and PII data should not be visible in the logs.

• Any user accessing the orders or payments DynamoDB table, including an AWS admin, must raise an operational alert.

8. Threats

Identifying potential threats, assessing their risks, analyzing the mitigation plans, and considering the action plans are the core aspects of threat modelling. Whether carried out by a single engineer or a group, this is where you spend most of the time in the process.

For each threat, record the following items:

• Threat type — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege.

• Threat — The description of a threat.

• Attacker — The type of attacker.

• Risk — The risk factor (usually High, Medium, or Low).

• Remediation — Measures to mitigate the threat.

• Verification of remediation — Steps to continually verify that the mitigation measures are in working order.

• Action — Actionable items due to the remediation and verification steps (either added along with each threat or collected in a separate section).

• Residual risks — Amount of a risk even after reducing with the mitigation plans (either added with each threat or collected in a separate section).

Reference example (the following table shows just a single threat per type, but in reality, there will be many under each section):

Threats

9. Actions

If not added as part of the table above, this is a list of all actions identified from the threat-finding activity. Most of these actions get raised as Jira tickets and tracked.

Reference example:

• Configure Cognito user pools, define API scopes, and set up authorizer.

• Create a runbook on how to invalidate an API client.

• Document structured logging policy for lambda functions.

10. Residual risks

The amount of risk is still possible even after implementing the preventive measures.

Reference example:

• A third-party monitoring application may corrupt or delete vital log data.

• A malicious user may attack the API in small batches at intervals, making it difficult to block.

Conclusion

Developing high-quality solutions takes time and effort. Though serverless enables us to speed up this process, building robust applications requires attention to detail. Threat modeling guides and helps you build secure cloud-scale solutions.

If you are new to threat modeling, start with a simple serverless architecture, then expand to complex solutions. Introduce it to a small team first and grow from there.

Let threat modeling be part of your serverless development best practice principles!