Don't use threat modeling to help you with the things you already have checklists for.

Do this because you want to understand the intersection of your stakeholder's goals and the architecture.

What is a Threat?

• An agent who attacks you?
• An attack?
• An attack's consequence?
• A risk?

What is a Threat Model

• Depiction of
  • The system's attack surface
  • Threats who can attack the system
  • Assets threats may compromise
• Some leverage risk management practices
  • Estimate probability of attack
  • Weight impact of successful attack

Threat

• Capability
  • Access ot the system
  • Able to reverse engineer binaries
  • Able to sniff the network
• Skill Level
  • Experienced hacker
  • Script kiddie
  • Insiders
• Resources and Tools
  • Simple manual execution
  • Distributed bot army
  • Well-funded organization
  • Access to private information
• Threats help
  • Encourage thorough throught about how intentions for misuse
  • Determine "out of bounds" scenarios

Threat Modeling as a Process

• Know thy enemy and how they attack you (who, what, how, why, impact, mitigation)

Threat Modeling - High-level Process

1. Diagram Structure
2. Identify Assets
3. Identify Threats
4. Stitch Threats onto Structure
5. Enumerate Doomsday Scenarios
6. Document Misuse/Abuse
7. Enumerate Attack Vectors
8. Iterate

1. Diagram the Software

• Different methods of diagraming (likes the whiteboard the best)

1.1  - Anchor in Software Architecture

Consider where attacks occur

Top-down

• Enumerate business objects
  • Sensitive data
  • Privileged functionality

Bottom-up

• Enumerate application entities
  • Sensitive data
  • Privileged functionality

Look for

• Middleware
• Open source
• Frameworks

1.2 - Identify Application Attack Surface

• Are there different privilege levels?
• Connectivity between services and processes

1.3 - Annotate with Design Patterns

• Are there pieces that whitebox testings is unable to analyze?
• What types of frameworks is the application using?
• Where are there command patterns?
• Where is there an inversion of control?

1.4 - Consider Patterns' Responsibilities

• Document specific standards for implementing each responsibility
• List out each pattern, piece of app, and associated standards

1.5 - Enumerate Potential Failures in Design Elements

1.6 - Find Key Structural Componenets

Component diagrams show critical choke points for security controls

1.7 - Identify Frameworks

Showing frameworks indicates where important service contracts exist 'up' and 'down'

1.8 - Explicitly Identify Controls

2 - Identify Assets

2.1 - Identify Critical Data Assets

• Do I have PII?
• Things that proxy for PII like sessions?

2.2 - Identify Interfaces as Proxies for Data

2.3 - Identify Assets flow through the System

• Assets exist not only in rest, but also flow through the system
• Think about where there are points you could stop the data from going

2.4 - Identify Critical Application Entities

2.5 - Identify 'Intermediate' Asset Objectives

Identify:

• Sensitive data
• Privileged function

Look out for:

• Proxies, facades, etc
• Services
• UI vs implementation
• Aggressive caching scheme

2.6 - Identify Equivalence-classes

• In essence an escalation of privilege connector
• Ex: Putting username and password and password reset questions on the same page puts them on the same equivalence-class without reauthentication and defeats the security control

3 - Identify Threat Agents

3.1 - Anchor Threats in Use Cases

• What is the dumbest things that a user can do?
• What is the most malicious thing a user can do?

4.1 - Identity Principal Resolution

• Arrows indicate resolution of principal/assertion propagation

4.2 - Place Threats on Diagram

4.3 - Show Authorization in Structure

• Coloration shows authorization by role
• Color modules by who you would need to be to access them and look where the colors change
• Has never NOT found a vulnerability for John

5 - Enumerate Doomsday Impacts

5.1 - Assign Threats Malicious Intent

• What is each Threat's motivation?
• What would drive escalation?
• Why would each try beyond the first hurdle?

5.2 - Instanstiate Doomsday Attack

6.1 - Add in Misuse Cases

Convert Actors to Threats

• Abuse - Make actors behave stupidly
• Misuse - Make actors deviant/evil

6.2 - 'Cache' Misuse in a 'Cookbook'

7 - Enumerate Attack Vectors

7.1 - Pilfer technology-specific security standards

7.2 - Pilfer community resources

7.3 - Pass technology-specific resources as your own

• When testing finds an attack:
  • First, decide if its impact warrants further exploration
  • Are additional impacts possible?
  • Consider what conceptual goals the attack supports
  • Then consider who could launch the attack against the application

• After analysis converges, iterate secure design

What is a threat?

• An agent who attacks you?
• An attack?
• An attack's consequence?
• A risk?

What is a threat model?

• Depiction of the system's attack surface, threats who can attack the system, and assets threats may compromise.
• Some leverage risk management practices.  Estimate probability of attack.  Weigh impact of successful attack.

Elements of a threat model

• Structural view
• Threat actors
• Assets
• Attack vectors
• Privilege/"trust"

Threat

• Capability: Access to the system, able to reverse engineer binaries, able to sniff the network
• Skill Level: Experienced hacker, script kiddie, insiders
• Resources and Tools: Simple manual execution, distributed bot army, well-funded organization, access to private information
• Threats help encourage thorough throught about how intentions for misuse and determine "out of bounds" scenarios.

A Few Words on STRIDE

• A conceptual checklist backed by data flow diagrams

Attack Trees

• Aggregate attack possibilites
• Use OR, AND
• Allow for decoration (probability, cost, skills required, etc)

Threat Modeling as a Process

• Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.

Leading Up to Threat Modeling

• Identify threats
• Enumerate doomsday scenarios
• Document misuse/abuse
• Diagram structure, assets
• Annotate diagram with threats
• Enumerate attack vectors
• Iterate

Input: Goals, Doomsday Scenarios

Misuse/Abuse Cases (use case view and component view)

Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")

Anchor in Software Architecture

Consider where attacks occur:

• Top-down: enumerate business objects (sensitive data, privileged functionality)
• Bottom-Up: enumerate application

Output: Security Assessment & Test Design.  Threat models drive assessments, Test design.  Establish rules of engagement.  Prioritize areas of interest.  Manage a team in risk-based fashion.  Establish a single tie between vulnerability and control.

Application Structure: No "One Size Fits All"

Application Structure: Topology - Coloration shows authorization by role.  Arrows indicate resolution of principal/assertion propagation.  Use structure to separate privilege.

Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).

Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".

Assets: Flow - Assets exist not only in rest, but also flow through the system.  Use different types of flags to represent data flow of assets.

Use different colored arrows to represent each different attack vector.

Target Using Layered Attacks: Bootstrap later attacks with those that "deliver".  Use one layer to exploit another (net, app).  Combine attacks to reach desired target.

Take Homes

• Base threat model in software architecture
• When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
• Enumerate initial attack vectors.  Use common low hanging fruit.
• Elaborate more attacks.  Find opportunities for privilege escalation.  Layer attacks to target or "hop" to assets.  Fill in gaps by "inventing" attacks.
• Use threat modeling to drive security testing