Threat Modeling with DFDs, STRIDE ———– 10/26/2020

You can’t prevent attempted security threats so STRIDE to protect yourself

STRIDE Security Threat Model

The STRIDE threat modeling goal is to get an application to meet the security properties of Confidentiality, Integrity, and Availability (CIA Triad), along with Authorization, Authentication, and Non-Repudiation. Once the security subject matter experts construct the data flow diagram-based threat model, system engineers or other subject matter experts check the application against the STRIDE threat model classification scheme.

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

Data Flow Diagrams

DFD based Threat Modelling is designed to visually represent a system or Process which enables teams to identify key processes and threats by following the flow of data.

Several Steps are used to implement this strategy

1. View System as an adversary:
   • Think Evil… Identify which processes and functions are visible and accessible to an attacker.
   • Using these exposed services formulate the goals to attack the system.
   • Identify the Entry/Exit points – Where data enters and leaves an application
     • Name and Numerical ID: Assign a name and id to each entry and exit point for cross referencing with threats and vulnerabilities.
     • Describe what exactly happens at each entry/exit point and identify the trust levels required at that point.
   • Identify the assets – The main goal of an adversary is to gain access to an asset.
     • Follow the asset where can it go, how can it change
2. Characterize the system:
   • Gather background information to identify areas that need addressed
   • Use scenarios
     • Stage situations/environments to show how a system will be used or not used
   • Track External Dependencies – Identify dependencies on outside resources and security policies.
     • Cross reference external dependencies to components within the application.
   • Implementation assumptions
     • Don’t leave system hardening as an assumption test against know misconfigurations