Threat Modeling

Manual for documenting threat models in Ketryx using custom item types

1. Introduction

Threat modeling is a structured approach to identifying and addressing potential threats to a system. This manual provides guidance on how to document your threat model using Ketryx with custom item types.

1.1. Purpose

The purpose of this manual is to instruct users on how to use Ketryx for documenting threat models, focusing on the STRIDE methodology.

1.2. Scope

This manual describes how to use Ketryx to document threat models in a system. It is intended for users who are responsible for identifying and mitigating threats to a system.

1.3. Regulatory Context

• AAMI TIR57: 2016/(R)2019: Principles for medical device security – Risk management

2. Terms and definitions

Acronym	Description
AAMI	Association for the Advancement of Medical Instrumentation
STRIDE	A threat modeling framework that categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
TIR	Technical Information Report

3. Project setup

To use threat modeling, you need to have a project set up in Ketryx Software Supply Chain Management. If you don't have a project set up, follow the instructions in MAN-03, section 3.

Additionally, you need to have the following item types set up in your Jira project and map them to the custom item types in Ketryx: Threat, Asset, Threat Source, Threat Surface, and Trust Boundary.

Once you have a project set up, you can start using threat modeling. The following sections describe how to set up the custom item types and map them to the Jira item types.

3.1. Advanced configuration

First, you need to activate the threat modeling feature in Ketryx and configure it to map the custom item types to the ones created in Jira. This can be done using the Advanced Settings called Custom item types, Item fields and Issue mapping.

To activate the threat modeling feature, go the Advanced Settings in your project or organization, and enable the Enable threat modeling setting.

Then, copy the configuration below and paste it into the corresponding fields in the advanced settings:

Item fields

{
  "Asset": {
    "addedFields": ["exposedByThreatSurface", "impactedThreats", "risks"]
  },
  "Threat": {
    "addedFields": ["risks"]
  },
  "Threat Source": {
    "addedFields": ["initiatedThreats"]
  },
  "Threat Surface": {
    "addedFields": ["containedInTrustBoundary", "exploitedByThreats"]
  }
}

Custom item types

[
  {
    "name": "Threat",
    "lifecycle": "LONG_LIVED",
    "shortName": "THR"
  },
  {
    "name": "Threat Surface",
    "lifecycle": "LONG_LIVED",
    "shortName": "THRSURF"
  },
  {
    "name": "Threat Source",
    "lifecycle": "LONG_LIVED",
    "shortName": "THRSRC"
  },
  {
    "name": "Asset",
    "lifecycle": "LONG_LIVED",
    "shortName": "ASSET"
  },
  {
    "name": "Trust Boundary",
    "lifecycle": "LONG_LIVED",
    "shortName": "TB"
  }
]

Issue mapping

[
  {
    "itemType": "CUSTOM",
    "issueType": "Asset",
    "itemTypeName": "Asset"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat",
    "itemTypeName": "Threat"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat Source",
    "itemTypeName": "Threat Source"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat Surface",
    "itemTypeName": "Threat Surface"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Trust Boundary",
    "itemTypeName": "Trust Boundary"
  }
]

3.2. Custom item types for threat modeling

This feature requires custom item types. If you don't have the required item types set up in your project, contact your Jira administrator to add them. It is recommended to copy the default Ketryx schema and add the custom item types to it.

For more information on custom item types, refer to the Custom Item Types reference.

The custom item types used for threat modeling are as follows:

• Asset: Represents an asset in the system.

• Threat: Represents a threat to the system.

• Threat Source: Represents a source of a threat.

• Threat Surface: Represents a part of the system that is vulnerable to a threat.

• Trust Boundary: Represents a boundary that separates the system from external entities.

When configuring the custom item types in Jira by following the Jira configuration guide, make sure to add the following fields (and any other you might require) when configuring the Screens:

For all item types, to make them so-called long-lived items, add the following fields:

• Introduced in version: The first version this item is effective in. If empty, the item is considered effective from the start of the project.

• Obsolete in version: The version in which the item is no longer relevant. If empty, the item is considered effective in all versions starting with its introducing version.

For the Asset item type, add the following fields:

• Introduced risks: The risks introduced by the asset.

• Impacted threats: The threats impacted by the asset.

• Exposed by threat surface: The threat surfaces that expose the asset.

For the Threat item type, add the following fields:

• Introduced risks: The risks introduced by the threat.

For the Threat Source item type, add the following fields:

• Initiated threats: The threats initiated by the source.

For the Threat Surface item type, add the following fields:

• Contained in trust boundary: The trust boundary that contains the threat surface.

3.3. Approval rules

By default, custom item types come with no approval rules configured. To do this go to Settings > Approval rules in the project you are setting up and add the necessary rules for the item types you have created.

4. Item types and relationships

The image below provides a visual representation of the relationships between key elements in the threat modeling process. It starts with vulnerabilities, which are weaknesses or flaws that can originate from components listed in the Software Bill of Materials (SBOM). These vulnerabilities are a starting point for potential security threats. For more information, please see the vulnerability management manual.

Once a vulnerability is identified in an SBOM component, it can be exploited by a threat. A threat represents a potential danger that can take advantage of a vulnerability to cause harm. This threat can then impact the software, specifically targeting the threat surface, which is the area or aspect of the system where vulnerabilities can be exploited. For more information about the SBOM module, please see MAN-03 Supply Chain Management: Software Dependencies.

The threat surface directly exposes assets—resources or valuable elements within the system that could be compromised. When a threat successfully exploits a vulnerability through the threat surface, it introduces a safety or cybersecurity risk. This risk represents the potential negative impact on the asset due to the exploited vulnerability. For more information on how to perform risk assessment for both safety and cybersecurity risks, please see MAN-08 Risk Management.

To manage and mitigate these risks, risk controls, or mitigations, are implemented. Risk controls are measures or safeguards put in place to reduce the likelihood or impact of the risk. Finally, these risk controls need to be validated to ensure their effectiveness, which is done through testing. Testing verifies that the implemented risk controls work as intended, thereby securing the assets from potential threats. For more information about test management, please see MAN-06 Test Management.

Not depicted in the diagram are the trust boundary and the threat source, two key concepts in threat modeling. The threat source refers to the origin of potential threats, such as external attackers, malware, or even internal actors that could exploit vulnerabilities in your system. While the diagram doesn't explicitly show the threat source, it is conceptually positioned outside or adjacent to the Threat element, indicating where these threats originate and how they begin to interact with your system.

The trust boundary is the line that separates different areas of trust within your system. It delineates the point where data or control passes from one trust level to another—typically from a more trusted to a less trusted zone or vice versa. In the context of the diagram, the trust boundary would be situated around the Threat Surface. This is because the threat surface represents the areas of the system that are exposed to interactions from outside the trusted boundary, where threats can exploit vulnerabilities.

The trust boundary is crucial because it defines where the system's security controls shift or where different security assumptions apply. External threats, crossing this boundary at the threat surface, pose a risk to the assets inside the system, and this is where the vulnerabilities are most likely to be exploited. Understanding the placement of the trust boundary helps in identifying the specific points where additional security measures may be needed to protect against threats originating from less trusted sources.

Threat modeling item types and their relationships

Within Ketryx, vulnerabilities can be linked to threats. In Jira, all the other item types can be linked to each other.

The above graphic does not depict all possible relationships between the item types, for example the relationship between vulnerabilities and risks, and risk controls. It is intended to provide a high-level overview of the key elements in the threat modeling process, not a comprehensive representation of all possible connections.