This presentation was by John Steven, the NoVA Chapter Lead and Senior Director of Advanced Technology Consulting at Cigital, Inc. He notes that this is not that MS thing, it is not going to help you find XSS, and is not going to help you with Risk Management. My notes are below:
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
- Diagram Structure
- Identify Assets
- Identify Threats
- Stitch Threats onto Structure
- Enumerate Doomsday Scenarios
- Document Misuse/Abuse
- Enumerate Attack Vectors
- 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
