Beginner's Practical Guide to Threat Modeling : Everything You Need to Know Get Started

OWASP 2021 - Insecure Design

OWASP had emphasized Insecure design in its 2021 OWASP top 10. which refers to flaws in the architecture and design of systems. Insecure design issues often require more fundamental changes within the product which are external to the code (Architectural and technology stack changes, Underlying OS, System hardening, Insecure configurations, Ineffective controls). Addressing these types of issues in a live production environment with public access can be extremely costly.

Threat Modeling : Shift-left security

To address Insecure design issues, OWASP recommends threat modeling, which is a proactive approach to security that involves identifying potential threats and vulnerabilities in software systems early in the development process. By integrating threat modeling into the Software Development Life Cycle (SDLC), organizations can achieve shift-left security, which means addressing security concerns earlier in the development process rather than waiting until later stages or post-deployment.

What & Why ?

What actually is threat modeling?

Threat modeling is a systematic approach aims to identify the attacks a system must resist and defenses that will bring the system to desired defensive state. It had been identified as best “return of investment” with respect to identifying and mitigating security issue early in the SDLC.

Why threat modeling should be adopted?

No Scan, Manual PT or code review identify the Design & Implmentation flaws

Ex: In most of the data breached organizations (Following security practices) Unable to identify intital access attempts, Laterval movements, and data exfiltration technicis with the traidtional assessment approach, nor there is information recorded to traceout actual threat actor.

When & How?

When should threat modeling be conducted??

Threat modeling can be conducted both for existing and new products. It is recommended that threat modeling should be conducted early in the planning or designing phases of SDLC and then can be refined throughout the life cycle of product development.

How is the threat modeling process carried out??

There are various methodologies and frameworks for conducting threat modeling, including STRIDE, DREAD, and PASTA, among others..

What is not considered

What is not considered as threat modeling

Several activities and practices are often mistaken for threat modeling but do not constitute threat modeling in the strict sense. Here’s what is not considered threat modeling in DevSecOps:

Code review - Code reviews focus on identifying issues in existing code base, whereas threat modeling considers the system’s architecture, data flow, and potential attack vectors

Penetration testing - PT is a reactive process addressing existing issues, while threat modeling is proactive activity aimed at preventing potential issues

Compliance audits - Compliance audits address existing policies,standards and controls, while threat modeling is a proactive approach aimed at eliminating misconfigurations & potential issues.

Prerequisites

Architecture - Architecture diagram, Component level diagram, Data flow, Network/Deployment diagram

Technology stack - (Web, app, DB server, API and open source framework products and version information)

Functionalities & User story - (Login&Registration, User roles & previleges, Input fields, Data management (CRUD), Business logics, File uploads, Third party integrations (Live chats)).

Existing Security Controls - Authentication, Authroization, Session, Input sanitization.

Methodology & Tools

Methodology - STRIDE

Security Frameworks - OWASP, CWE, CVE, MITRE Attack

Tool - Threat dragon, Microsoft Threat modeling tool

Project Deliverables

• 1. List of possible threats
• 2. List of second and third order threats (Ex:otp bypass, JWT)
• 3. List of mitigations and recommendations
• 4. Priotitized list of threats (Based on the likeli hood * business impact)
• 5. Best practices

Threat Modeling : Phases

Threat modeling for new products should be conducted across each SDLC phase of product development which includes

• 1. Planning
• 2. Requirement analysis
• 3. Design
• 4. Implementation
• 5. Testing
• 6. Deployment

STRIDE MODEL

STRIDE threat model is a framework used to identify and categorize potential security threats in a system. The acronym STRIDE stands for:

Threat Modeling : Procedure

What are the steps involved in conducting threat modeling?

• 1. Examine the architecture and its components in detail.
• 2. Gain insight into the implemented functions, features, and business logic.
• 3. Create a Data Flow Diagram based on the information gathered in each phase.
• 4. Flag threats based on DFD.
• 5. Create a list of threats and map countermeasures.
• 6. Evaluate the results.

Threat Modeling : Steps in Sequence

Decomposing the application for Threat modeling

• Step 1 : Identify External dependencies - Refer to architectural & infra components, which are external to code and list them down.
• Step 2 : Identify Assets - Refers to things that the attacker is interested in, credentials, PII, sensitive data part of the application and list them down.
• Step 3 : Identify Entry points - Interface where attackers can submit malicious content (Input fields/parameters) and list them down.
• Step 4 : Identify Exit points - Where submitted data leaves the system (Dynamically reflected data into web page) and list them down.
• Step 5 : Identify trust boundaries - Represents access rights and privileges granted to various components, entities or systems within the system architecture and list them down.

Threat Modeling : Data Flow Diagram

Mapping threats and mitigations

Mapping threats and mitigations

Mitigation order

Defense in Depth (DID) is a comprehensive cybersecurity strategy that employs multiple layers of security controls and measures to protect information and systems. The concept is akin to a multi-layered fortress where if one line of defense fails, additional layers continue to provide protection. This approach aims to ensure that a single point of failure does not compromise the entire system.

How can we assess the work

• Is your DFD covering all the aspects
• Do you have list of potential threats
• Do you have mappings of countermeasures with identified threats
• Do you have list of ordered threats and mitigations
• Does all the stakeholder agree on Diagram and threats