Wilson Mar bio photo

Wilson Mar


Email me Calendar Skype call

LinkedIn Twitter Gitter Instagram Youtube

Github Stackoverflow Pinterest

This is perhaps the most impactful analysis, considering the importance and urgency of keeping your organization from being stolen

US (English)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean


UNDER CONSTRUCTION: Each line and box in the busy flowchart above will be converted to a video with gradual reveal.

This is a deep dive with commentry and warnings.

NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.

There are MANY approaches:


Let’s start with OWASP’s summary of the process:

  • Step 1: Decompose the Application (Data Flow Diagrams showing External Dependencies, Entry Points, Exit Points, Assets, Trust Levels)

  • Step 2: Determine and Rank Threats (such as Microsoft’s STRIDE)

  • Step 3: Determine Countermeasures and Mitigation (such as ASF)




Microsoft’s STRIDE

1999, cybersecurity professionals Loren Kohnfelder and Praerit Garg at Microsoft developed the acrostic “STRIDE” for their Threat Model Tool used to classify threats in applications:

  • Spoofing of user identity
  • Tampering
  • Repudiation
  • Information disclosure (privacy breach or data leak)
  • Denial of service (DoS)
  • Elevation of privilege


In 2004, Frank Swiderski and Window Snyder wrote “Threat Modeling,” by Microsoft press. In it they developed the concept of using threat models to create secure applications.






PASTA (Process for Attack Simulation and Threat Analysis) (created in 2015 by Tony UcedaVelez and Marco M. Morana) is a attacker-centric methodology for dynamic threat identification, enumeration, and prioritization.

It provides a seven-step process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis.

After the threat model is created, security subject matter experts develop a detailed analysis of the identified threats. Finally, appropriate security controls can be enumerated.

Defenders then take an asset-centric mitigation strategy around applications and infrastructure.

Utilities needed

But if you’re serious about this (and you need to be), you’ll need a utility to store all the data for dicing and slicing (visualization).

Synopsis.com has a 5-step approach (for your money’s worth):

  1. Define the scope and depth of analysis. Determine the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.

  2. Gain a visual understanding of what you’re threat modeling. Create a diagram of the major system components (e.g., application server, data warehouse, thick client, database) and the interactions among those components.

  3. Model the attack possibilities. Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system. Then identify what could go wrong (i.e., the threats) using methods like Microsoft’s STRIDE.

  4. Identify threats. Produce a list of potential attacks by asking questions such as:

    • Are there paths where a threat agent can reach an asset without going through a control?

    • Could a threat agent defeat this security control?

    • What must a threat agent do to defeat this control?

  5. Create a traceability matrix of missing or weak security controls. Consider the threat agents and follow their control paths.

    If you reach the software asset without going through a security control, that’s a potential attack.

    If you go through a control, consider whether it would halt a threat agent or whether the agent would have methods to bypass it.



More on Security

This is one of a series on Security in DevSecOps:

  1. SOC2
  2. CAIQ (Consensus Assessment Initiative Questionnaire) by cloud vendors

  3. Git Signing
  4. Hashicorp Vault
  5. OPA (Open Policy Agent)

  6. WebGoat known insecure PHP app and vulnerability scanners
  7. Test for OWASP using ZAP on the Broken Web App

  8. Encrypt all the things

  9. AWS Security (certification exam)
  10. AWS IAM (Identity and Access Management)

  11. Cyber Security
  12. Security certifications