Introduction

Threat modeling is a procedure for optimizing application, system or business process security by identifying objectives and vulnerabilities and then defining countermeasures to prevent or mitigate the effects of threats to the system

Every security team has to deal with one question: “Are my services/deployments secure?”

Answering this is non-trivial, and involves understanding the threat vectors faced by the services. To understand threat vectors one needs an understanding of how the services work, what communication primitives are used, how is the data stored and how is the access governed. The threat vector will be different for different services or different deployments of a given service.

Threat modeling helps the security or development team to understand the possible threats to the given system or deployment.

The input to threat modeling could be a system design or a deployment architecture with the specified trust boundaries. The output of a Threat modeling activity is a list of possible threats to the system/deployment. The team can then evaluate each of the possible attacks and provide a mitigation or investigation strategy.

Zero Trust and Trust Boundaries in the Threat Model

ZTA (Zero Trust Architecture) assumes there is no implicit trust granted based solely on the physical or network location or based on asset ownership. Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.

The trust boundaries in the threat model allowed one to configure a trusted domain within which the services could trust each other. ZTA removes any such assumptions i.e., even within the trust boundaries of a threat model the services have to authenticate and authorize explicitly.

Templates used by the Threat model should consider the ZTA aspect and should not assume implicit trust within the trust boundaries. The trust boundaries in essence would only indicate operational/management boundaries for the system.

STRIDE Approach

While there are multiple approaches for Threat Modeling, the STRIDE approach pioneered at Microsoft is the most popular approach in software engineering. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

STRIDE requires one to decompose the system into components, modules and identify relation (connectivity) between them. You establish what is the trust boundary for the modules or group of modules and then generate a report. The report essentially explains the susceptibility to the threats. The design or the security team could then evaluate individual threats and investigate them.

When should Threat Modeling be done?

Trust boundaries and threat indicators will change over a course of time as the design evolves and so should the Threat Model of a given system.

Threat Modeling is not a one-time activity and it should be tied up to the design updates of the given system as part of the software development/deployment lifecycle. It is advisable to integrate it as part of the software development life cycle, especially whenever the new requirements result in a design or deployment architecture impact.

Who should do it?

Development Team (Systems Engineer): A dev team should consider making Threat modeling an integral part of the design specifications. Typically the design is used by the QA team, and by the documentation team for further derivatives such as Test design and documentation design. A Threat Model could help the QA team to better understand the security aspects of the design and prepare a test design for the same.

Security Team: Threat Modeling enables a methodical approach for the security team to identify possible threats in a given system. The generated threat report can then be used to evaluate the actual threats.

How to do Threat Modeling?

Microsoft provides a Threat Modeling Tool (MS TMT) that allows not only to prepare a model from given templates but it also allows new templates to be created for different systems. (Brilliant work MS, and thank you for making the tool available to all).

We have prepared a new template that works with MS-TMT specifically for Kubernetes-native applications and modeled the open-source k8s-native tool KubeArmor. The k8s-template allows to import k8s entities such as pods, daemon sets, services, deployments, etc into the model and use k8s-specific trust boundaries such as “cluster trust boundary”, “node trust boundary”, “namespace trust boundary”.

The k8s template and the KubeArmor Threat Model along with its Threat Report is available in this repo.

Step-By-Step Guide for Threat Modeling

This article will focus on the STRIDE approach for threat modeling and will be using Microsoft’s MS-TMT app. We have prepared a k8s-stencils-template that could be used with the tool making it easier to model applications, services, agents based on k8s-native philosophy.

Tool Preparation

Download MS-TMP app
Download k8s-stencils-template
Note that the k8s-stencils-template is a work in progress…

Model Preparation

This step involves:

• Preparing a system’s interaction diagram or deployment architecture
• specifying the trust boundaries Reuse existing system design diagrams and apply trust boundaries as necessary.

Note that it is not necessary to get all the interactions correct in the first phase. You can have a simplistic view and then later keep on adding new entities/components to your model and apply new trust boundaries.

KubeArmor Threat Model

Report Generation

Once the model is prepared click on “Switch to Analysis View” to check all the detected threats.

To get a detailed report use, “Reports -> Create Full Report…”. The report would be saved in an HTML file. For a sample report, check here.

Threat Analysis

For the reported threats provide an analysis, stating whether:

• the threat needs Investigation
• it is “Not Applicable” and provide a justification
• it is Mitigated because of some action already taken

To Sum Up

• STRIDE approach for Threat modeling provides a methodical approach to identify threats in a system
• The k8s-stencils-template for the MS-TMP app provides an easy way to threat model the k8s-systems.

Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.

Let us know if you are seeking additional guidance in planning your cloud security program.