This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.

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