Manual Threat Modeling

This guide will help you through the Oplane threat modelling process. The process has three distinct steps:

  1. Threat model setup
  2. Design refinement
  3. Requirement assessment

1. Threat Model Setup

To achieve a good threat model assessment Oplane needs some context about the system and change it is threat modelling. The context comes mainly in two parts: the source code repository of the system, and a change description.

Source Code Repository Import

The first step of the threat model setup is to select which source code repo to use. Oplane will allow you to directly import your source code repo from Github.

Press the Continue to Github button, authenticate the Oplane app and see the source code repos of the selected organization, allowing you to search for any repo involved in your change.

GitHub repo selection

Once a source code repo is selected you can repeat this process for any number of services or apps involved in the change, whether it is frontend, backend or some other related service.

Multiple repos selected

Design Import

Once the baseline (the system description) is established using the existing source code, the next step is to define the change description—a short text describing what you are changing in your system.

First, set a reference name for the change you are doing (i.e. a feature name). This will allow you to find your way back to the threat model later.

Feature name input

If you have the change documented somewhere else (such as in a feature design document), Oplane offers import functionality from Jira and Miro. Click on the appropriate icon, authenticate using OAuth and paste the relevant resource link.

Import from Jira or Miro

Once you have completed the import, the Oplane agent will generate a design description from the sources. This is a short text document that will be the source of truth of what change is being assessed.

Important: Go through the generated document and make sure it is correct. Fill in any missing information the Agent has marked (such as "TODO: Please provide any information here").

Design description

2. Design Refinement

With the system baseline defined and the change description completed, the next step is to clarify uncertainties regarding the design. This typically involves decisions regarding overall data flow, possible implementation choices, or how different security concerns will be addressed.

In Oplane, this design refinement is handled through an interactive session where the Oplane agents ask detailed and specific questions regarding these choices.

Design refinement questions

Your task is to go through the questions one by one and answer them to the best of your abilities. With each question the agent will provide some likely answers for you to select, but you can also add your own option if none of the options are correct.

Answering questions

Some questions will be single choice while others will be multi-choice. You can also skip questions if you find them not relevant, haven't decided yet, or find the question unclear.

Multi-choice questions

After each answer the agent may choose to ask more questions, creating an ever clearer image of how the implementation will look like. At any point, if you feel the detail level is good enough, you can choose to skip these questions and move on to the next stage.

Follow-up questions

3. Requirement Assessment

The outcome of an Oplane threat modelling session is a set of requirements. These can be seen as security concerns you will need to address in order to build a safe system. Some of these you will likely already be aware of, while others will be new.

Requirements overview

Each requirement comes with:

  • A short description
  • A rationale of why it is important
  • A consideration of what might happen if you do not address the concern
  • A business risk describing how this might affect the business
  • A suggested solution detailing how to solve the problem
Requirement details

Tip: Read the suggested solution carefully to make sure you fully understand what is required to solve the issue. It is otherwise easy to only solve part of the problem!

For each requirement, you need to decide if you intend to implement this, if the security concern is not applicable in this case, if it is already implemented, or if you accept the risk.

Assessing requirements

For each requirement you can also add a motivation and keep discussing the concern internally using the comment section.

Adding comments

Once you have assessed all the requirements, press Complete threat model. This marks the end of the process and depending on your organization may kick off additional automations such as syncing the requirements back to your Jira workflow.

Complete threat model