LP Threat Modeling Outline

Use the LP Threat Modeling Template to fill out the following information

1. Define the Scope and Application Objectives
   • Define the Scope
     • To what extent the threat model will cover
     • A threat model scope defines what is relevant, within a particular view
       • There can be multiple scopes, or views, that pertain to a single application
       • Typically there should be two scopes: Application and Infrastructure
         • The application scope is the use case / application's functionality
         • The infrastructure scope consists of how the application is compiled, tested, and stood up
   • Define the Purpose of the Application
     • What functions the application provides
   • Define Business Objectives of the Application
     • How this application benefits the business
   • Define the Application's Security Tier
     • Tiers range from 1 to 3, with Tier 1 being the minimum that all software must adhere to
     • This tiering system is derrived from OWASP's Application Security Verification Standard v3.0.1, pages 8-12
       • Reference the ASVS for more detail on the following tiers and a checklist of requirements for each level
     • Tier 1 applies to general software
       • Coincides with ASVS Level 1
       • The software must adequately defend against application security vulnerabilities which are easy to discover
         • Refer to OWASP Top 10 and other similar checklists
     • Tier 2 applies to applications that contain sensitive data or controls
       • Coincides with ASVS Level 2
       • The software must have effective security and monitoring controls in place, which are used within the application
       • The software must adequately defend against most risks associated with software to date
     • Tier 3 applies to applications that perform critical functions, where failure could significantly impact the organization's operations and/or survivability
       • Coincides with ASVS Level 3
       • The software must adequately defend against advanced application security vulnerabilities
       • The software must demonstrate principles of good security design
   • Define Compliance Requirements
2. Decompose the Application
   • Draw/Update Control Flow Diagrams using the Diagram Syntax
     • Application Threat Model Diagram (Example ATMD 1) (Example ATMD 2)
       • Diagram of how the app works in production
       • Use case diagram / data flow diagram
     • Infrastructure Threat Model Diagram (Example ITMD 1) (Example ITMD 2)
       • Diagram of the system infrastructure and how the app is deployed
   • List user roles and their permissions
     • This is a list of what actions each role should be able to do
3. Identify Assets
   • Identify Assets
     • Items/areas of interest to an attacker
     • The things that this application needs to secure
   • Identify External Dependencies
     • external entities that would keep the application from functioning properly if removed
4. Identify Threats and Analyize Risk
   1. Create a Threat Traceability Matrix (Example TTM)
      • The simplest way to create this is to use Excel and save the matrix as a CSV file, then throw the CSV into a markdown table generator
      • Look at each asset individually while considering which categories of STRIDE may apply.
        • __S__poofing
        • __T__ampering
        • __R__epudiation
        • __I__nformation Disclosure
        • __D__enial of Service
        • __E__levation of Privilege
      • Play the Elevation of Privilege card game
      • Each threat should be listed as a new row in the Threat Matrix, which has the following columns
        • STRIDE Category
        • Interaction (Connection details between the user and the application using the Interaction Syntax)
        • Exploit Description (The type of attack performed by the malicious user)
        • Attack Surface (All of the different points where an attacker could get in and get data out)
        • Impact (What is the impact if this is exploited)
        • Mitigation (How can we stop or prevent this threat)
   2. Reorder the threat traceability matrix from highest to lowest risk
      • Security Tier 1 applications
        • Rank threats relative to each other to get a comparative list
      • Security Tier 2 applications
        • Rank threats numerically with the 5x5 Risk Matrix
        • Likelihood Ranking Definitions
          • Rare: it may not happen in a lifetime
          • Unlikely: this will occur every so often
          • Moderate: it will happen regularly
          • Likely: this will be a frequent problem
          • Almost Certain: it will happen constantly
        • Consequence Ranking Definitions
          • Insignificant: slight, possibly unnoticeable impact. Business unaffected, maybe a phone call is needed
          • Minor: temporary loss of service that does not affect the customer. Business experiences a hiccup in operations
          • Significant: loss of sensitive data or service for an extended amount of time, possible financial loss
          • Major: major loss of sensitive data or an interuption of critical services, business will experience financial loss
          • Severe: complete destruction or theft of data and rendering a service unrecoverable. Extreme impact to the business and it's survivability
      • Security Tier 3 applications
        • Rank threats using the CVSS
        • Online CVSS Calculator

Assessing the Threat Model

How good is the threat model?

How to assess the threat model's effectiveness based on the Application's Security Tier:

• Tier 1 Application
  • General reflection on the artifacts generated
• Tier 2 Application
  • General reflection like in Tier 1 with additional self-performed penetration tests
• Tier 3 Application
  • Professional penetration test