Menu

Introduction to PCI DSS (Payment Card Industry Data Security Standard)   Introduction to PCI DSS (Payment Card Industry Data Security Standard)   

Data Protection Act 1998   Data Protection Act 1998   

Secure HTML Practices   Secure HTML Practices   

SQL Injection Attack - Introduction and Mitigation Steps   SQL Injection Attack - Introduction and Mitigation Steps   

Cross Site Scripting (XSS) – Introduction and Mitigation Steps   Cross Site Scripting (XSS) – Introduction and Mitigation Steps   

Audit and Testing Tools for Web Application Security   Audit and Testing Tools for Web Application Security   

Threat Modeling for Web Application Security - Practice Guide   Threat Modeling for Web Application Security - Practice Guide   

Threat Modeling for Web Application Security - Practice Guide

Published on: 8/15/2014
Topic: Web Application Security
Threat Modeling is Risk Analysis Exercise that can be applied to not only a software product but to any asset that is valuable to your organization.

This is an iterative exercise and it may not be possible to ensure 100% coverage or do it 100% correct in first go. Ideally you should start by protecting outer trust boundry and then continue securing internal layers and sub-components of your application.


Table of Contents

Threat Modeling – Key steps


Before We Start

If you are new to threat modeling then you should first have a quick look at following terminology sections:

Data Flow Diagram
STRIDE Model
DREAD – Risk Rating Model


key steps
The key steps of threat modeling process are as following:

1. Break down your product architecture using Data Flow Diagrams

2. Use STRIDE threat categories to identify what threats are applicable to each element of DFD.

3. Map all threats with relevant Vulnerabilities as applicable in context of usage scenario.

3. Assign Risk rating to each threat & vulnerability to understand the impact that would help to define the priority for fix

4. Define the mitigation plan/countermeasures for each vulnerability

5. Fix the vulnerabilities that are not acceptable to business in order of priority as decided in above steps.

Think about below aspects before you start


Understand the user context

Below categories are applicable in most of dynamic applications:

1. User who is not supposed to have any access to your app. Think about all means by that he may try to get the initail access.

2. User who gets access to your application in capacity of normal user. Think about all means by that he may try to escalate the privileges.

3. The user who is allowed access to admin functions or provided direct access to contents from backend database and he may misutlilize his authority.

4. Attaker who would compromise the web/front end server getting escalaed privilege on all resources available on this server. He may try to exploit the trust relation with application & Database server and he may get access to critical information from access/event logs or configuration files.

You should assume that all inputs provided to application are malicious and all trust boundries may be breached by attacker especially the 1st level i.e. first interaction layer between end user & product.

Static sites and social platforms are subject to lesser threats in comparison to data centric applications although the impact of vulnerabilities like Cross Site Scripting in a social/static site could be much more damaging.

Similarly web sites hosted in cloud or in a shared hosting environment would have different challanges.


Continue Reading: Sample use Case