Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Realistic Threat Modeling

Sharing session emphasizing practical aspects of modern and effective threat modeling.
by

Fabio Arciniegas

on 11 August 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Realistic Threat Modeling

(Realistic) Threat Modeling
Microsoft Threat Modeling tool
Drawing a DFD
Fabio Arciniegas, Infosec 2017
Analyze with STRIDE
Data Flow Diagram
- Captures process, trust boundaries, data stores, and the flows between them

- Pioneered by Microsoft.

- Consistent starting point for STRIDE

- Start with a simple, general view, expand and annotate as needed
STRIDE
S
poofing
T
ampering
R
epudiation
I
nformation disclosure
D
enial of service
E
levation of privilege
Impersonating something or someone else
Spoofing
Fake DLL pretends to be tmms.dll
Person claims to be You
DNS entry directs user to fake site
Key Property: Authentication
Modifying data or code, in transit or at rest
Tampering
Modifying a DLL on disk
Packet as it traverses the network
Key Property: Data Integrity
Claiming to have not performed an action.
Repudiation
I didn't send that email
I didn't modify that file or made that request
n people share an account, logs cannot reflect who accessed
Key Property: Non-repudiation
Exposing information to someone not authorized to see it.
Information Disclosure
extract secrets from error messages
sensitive files with open permissions
secrets without encryption
Key Property: Confidentiality
Deny or degrade service to users
Denial of Service
DDoS
Crashing the OS
Sending a packet and absorbing seconds of CPU time, or routing packets into a black hole.
Key Property: Availability
Gain capabilities without proper authorization
Elevation of Privilege
Remote internet user to run commands through weak authorization check
Corruption/prediction of authorization token
Key Property: Authorization
Attack Trees
- STRIDE helps us find big areas of interest and missing/problematic security mechanisms
SECURITY-ORIENTED MODELS
DOMAIN KNOWLEDGE
authentication
integrity
non-repudiation
confidentiality
availability
authorization
Data Flow Diagrams
STRIDE
Microsoft TM tool
- But how to question if the existing mechanism is good enough?
- Often you work with a standard architecture, framework, or better yet Services (AWS).
What to look for then?
Others
Asset based analysis
Risk rankings
Many "kinds" of analysis you may hear about
What is worth stealing in this system? what would an attacker be after?
The way to work this is Annotating existing models with assets (as we did in the ticketing system)
Sound good but important assets are often very predictable (e.g.PII, IP) and most effort should be spent on the analysis of mechanisms and services protecting them.
Capturing Results
Don't:
separate word document
long text explanations
force every idea into a "threat template"
- Versioned file (text or spreadsheet) with
actionable items and owners
- Reuse formats/tools you have for your code and
project management (e.g. JIRA, sheets, .md in git)
People speak of Risk = damage*likelihood
Nice illustration of a way of thinking but must not be confused with actual measurements or an end point for priorities.
Q: what is the value of the likelihood of "dns poisoning" multiplied by impact of "loss of reputation"?
These are just coarse buckets. Don't waste time doing these diagrams. Just treat as a first form of grouping (quick table) and know that common sense and priority arbitration will be needed.
Example of an efficient output
TRADITIONAL BEST PRACTICE LISTS (text)
SECURITY AS SERVICE
COOKBOOKS (code)
Authentication
Reusing and transmitting expertise.
Encryption
Input Validation
Error handling
Sometimes people use the word "analysis" to refer to an area of interest. This doesn't mean is a different kind of analysis.

You may stumble upon talk of things like "limited resource analysis"
"Limited Resource Analysis"
- Look at shared resources in the OS such as sockets or process ids.

- Look into high availability, plan for escalation
"Log and auditing analysis"
- Think about the the traces left behind by credential and identity theft, social engineering etc.

- Make sequence diagrams that show logging behavior
We just treat these as areas of domain knowledge and use them opportunistically according to the system and the quality of the content.
where do you find these?
Key management Service bit.ly/1QQXmd7
Identity bit.ly/1WSO8LV
Authentication and Credentials Mgmt bit.ly/1LsgN9V
Storage /bit.ly/21yfNbE
RDBS bit.ly/1UvvACI
Authorization and roles bit.ly/1WSO8LV
bit.ly/1neePhC
For more visit appsec.trendmicro.com
This presentation is available in prezi:
General Process of Threat Modeling
General Elements of Threat Modeling
- High-level structural diagrams (aka architectural)
- UML Class/Object/Deployment Diagrams
- Sequence Diagrams
- Data Flow Diagrams, STRIDE

- Mechanism Cookbooks
- Attack Trees

- "
Data Sensitivity Analysis"/Asset analysis
- Attacker Profiles
- Risk Impact/likelihood Matrix

The Goal of Threat Modeling
Why are we talking about this now?
For years we have done some forms of Threat modeling.
In recent months interest has increased:

- From motivated teams
- From management committed to better Security practices
- From teams experiencing trouble
Frame one discussion:
"what could go wrong with this design?"
What is not:

- How to create FUD (Fear Uncertainty Doubt)
- Do every single technique regardless of value
- Propose more work regardless of schedules
1 Model System : what are you building?
2 Find Threats: what can go wrong?
3 Address Threats: what should you do about them?
4 Validate Threats: did you do a good enough job?

Q:KEY FOCUS?
(Unless you have a financial
motivation for writing long documents)
The context of the AppSec Practice
Threat Modeling is only one piece in the Application Security practice.

Company-wide and lifecycle-wide ongoing effort by Infosec.
http://appsec.trendmicro.com

* Portions of a Design Review from a _better_
external

- **Discovery:** Sifting the important (security-related) elements from the sea of details
- **Analysis**: Looking into the security of elements under investigations
- **Substantiation**: Theoretically or practically demonstrating the
security problem

High level structural models (aka Architectural diagrams)
Classic High Level Architecture Diagram
(good ol' boxes and arrows)
Pros
Sequence Diagram
- Accurate description of sequence of events
- Can include relevant low-level details
- Very useful in practice. Obviously cannot be made for every interaction.
- Cherry-pick based on areas of interest/typical fails (e.g. authentication)

- Good for inspecting structure at a detailed level.
- Help discuss security implications of classic bad design such as:
- poor encapsulation
- high coupling
- low cohesion

UML Structure Diagrams
Can help annotate sensitivity
So

- Pick the right models (models that allow reasoning and generate actual action items)
- Honestly emphasize the parts that are needed (drop what is not)
- Leveraging the tools and techniques that consume less time and money
Models worth doing illuminate security aspects

Knowledge worth having can be clearly transmitted

Be Succinct. Use the extras only when they truly add value (nobody reads 30 page word documents)
IaaS HLA
A base for discussion but also a versioned asset that can be refined
Important to note because the more mature the platform used, the more security becomes a matter of configuring security mechanisms and less about creating them.
Preliminaries
+
I work in Trend Micro's Infosec. Before that:

Security consultant
Project manager, Technical lead
Standards co-author
Author
Developer
I understand the perspective of different roles (why developers want to go code, managers save time, and consultants to sell) and have no intention of wasting our time with anything that is not of practical value.
A note about me
What benefit can you expect from this content?
Improve
your ability to reason about the security of a system
Know
how to model systematically the security-relevant aspects of the product
Know
how to start the analysis and probe into the model
plus a few straight answers about what is useful and what is not in the literature about Threat Modeling
Why
What
How
}
MODELS
}
Domain
Knowledge
}
Extras
Three high level rules for efficient threat modeling
Threat Modeling combines a model and domain knowledge to help reason about the
security of a system.
What kind of models do people use?
- Usually it exists already
- Allows talking about top components
- Can start as simple as network diagram
- May include primary user types
- Areas of further interest may be easily annotated
Cons
- Varies greatly in quality and detail
- No universal conventions
- May show or hide security-relevant
aspects
- Usually hindered, not helped by
people's creative expression
(42 colors, 4 unexplained arrow types
etc.)
Not so good for discovering missing security aspects
(before this class)
our main goal: learn to make the most useful, efficient models to help us think through design security.
If you work a lot with AWS you should look into our course for AWS and Security DevOps
at appsec.trendmicro.com
Do :
Walk-through exercise
Quick 5 minute warm up
what can go wrong with this?
Security-oriented
What makes a model security-oriented?
It highlights the key areas and properties that have security implications

It elides (leaves out) areas and decorations that do not
which properties?
externally
internally
appsec.trendmicro.com
http://lmgtfy.com/?q=foo+best+practices
Negating Attack trees
requires more expertise on attacks (since they are the starting point)
"impersonate user" {
"steal credentials" {
....
},
"steal session" {
"predict session id",
"replay session",

"force session id"
....
}
}
<- Cryptographically random ids by library x
<- SSL with full forward secrecy per company
standard configuration
<- Anti session fixation turned on in framework
foo
https://www.schneier.com/academic/archives/1999/12/attack_trees.html
(NEGATING) ATTACK TREES
Now we need ways to reuse and transmit expertise and match the system against it.
Inspecting further
The more physical,custom, or non-standard the system is, the more worth it is to think about which assets might be overlooked
Things you might hear/read about re: Threat Modeling (but we don't spend much time on)
A: "high?" a point in a nominal scale of 4 values.
Q: what STRIDE property refers to this?
Q: what is the related STRIDE property?
=
RESULTS
An internal note
What we expect you to prepare before starting
analysis with Infosec:
Data Flow Diagrams
Browse through essential mechanisms checklist (http://bit.ly/29v16Rm)
Browse through service security considerations if using AWS (http://bit.ly/29v1D5H)
Attack Trees
List started with items you already know
New Analysis
New Sequence Diagrams
Open http://bit.ly/29xzJHS
and inspect the different layers.
Consider an app that captures events
on a client and aggregates them in AWS.
outputs should be action items,
Thing sprint backlogs (todo lists), not reports (word documents)
<draw>
<open ms tool 2016>
Open http://bit.ly/29o5xfX
and see how we capture issues
Open http://bit.ly/29zPuv0
and see a "zoom-in" DFD into the Windows Client
Open http://bit.ly/29PUjPy
and see sequence diagram for authorization issue
Full transcript