Skip to content

Latest commit

 

History

History
98 lines (93 loc) · 6.95 KB

README.md

File metadata and controls

98 lines (93 loc) · 6.95 KB
Raw

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

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