Scribd
Upload
42 views54 pages

Day 2 Session 01

Day 2 Session 01

Uploaded by

sferdinandes510
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views54 pages

Day 2 Session 01

Day 2 Session 01

Uploaded by

sferdinandes510
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 54

Introduction to

Application Security
EMSC - IS
Introduction to Threat
Modeling
Threat Modeling
A systematic & structured security technique, used to identify the
security objectives, threats & vulnerabilities of an application, to
help make design and engineering decisions, and determine
where to prioritize efforts in designing, developing and deploying
secure applications
It's a day-to-day phenomenon for all of us :
Assets (e.g. Photos, Jewelry)
Architecture/Design of you home
Attackers (Burglary)
Threat Modeling
Threat modeling answers questions like :
“Where are the high-value assets?”

“Where am I most vulnerable to attack?”

“What are the most relevant threats?”

“Is there an attack vector that might go unnoticed?”.


Why Threat Modeling
Systems have been vulnerable due to :
failures in identifying all potential risks by the analysts

failures in detecting the loopholes (e.g., access control) by test


engineers

incorrect implementation of best coding practices and


programming logic

improper system deployment and maintenance (configuration


level)
Why Threat Modeling
Without threat modeling, protecting yourself is like
“shooting in the dark”

You need expertise in understanding most common


attacks - read security bulletins

Developers must learn and use secure coding practices

Assume you are vulnerable, prove you are not


Common Types of Attack
Common Types of Threat
Find Security Issues | After
Static analysis of code
Fuzzing or other dynamic testing
Pentest/red team
Wait for bug reports after release
Find Security Issues | Before
Threat modeling
Think about security issues early
Understand your requirements better
Don’t write bugs into the code
Challenges
Time consuming process
Difficult to show demonstrable ROI
Fairly dry stuff to do
Terminology
Assets – a resource of value. May be tangible or intangible.
Threat – Undesired act that potentially occurs causing compromise or
damage of an asset.
Threat Agent – Something/someone that makes the threat materialize.
Vulnerability – Weakness that makes an attack possible
Attack – Act of malicious threat agent.

Safeguard (Countermeasure) – address vulnerabilities (not threats


directly) Ex – Application Design, Writing Secure Code, deploy with least
privilege
Terminology
When to Threat Model
Best performed during the application design phase
Easiest to make application changes

Less costly than adding mitigations and testing them after code
has been implemented and onwards
Who should Involved
Architect - The desire is to create a threat model early in the
design phase, to influence subsequent design decisions.

Business Analyst - The business analyst answers and clarify


questions regarding the security objectives and primary use
cases.

Developer - The developer wants to understand the security


implications of various design and implementation choices.

QA Lead - The QA lead wants the threat model to help define


the test strategy to focus his security testing.
Threat Analysis - Attack Trees
Attack tree is a tool to evaluate the system security based on
various threats.
The root of a tree represents a security event that can
potentially damage an asset.
Each attack tree enumerates the ways that an attacker can
cause an event to occur.
Threat Analysis - Attack Trees
Each path through an attack tree represents a unique attack. A
system can have a forest made up of many such attack trees.

Node of an attack tree is decomposed through either an AND-


decomposition or an OR-decomposition.
Threat Analysis - Attack Trees
Threat Analysis - Attack Trees
Attack Tree - Steal a Car
Attack Tree - Steal a Car
Attack Tree - ATM Machine
Attack Tree - Bank Account
Use and Misuse Case
Think Like an Attacker

Thinking like an attacker to focusing on them is risky


What do they know?
If you get these wrong, your threat modeling will go wrong

Do not start from Attackers !


Focus on Assets
Assets
Valuable things that business cares
Something that business wants to protect
Something Attacker Wants
Ex.
Private data (e.g., customer list)
Proprietary data (e.g., intellectual property)
Potentially injurious data (e.g., credit card numbers, decryption keys)
Create Architecture Overview
Define what the application does and how it's used
Users view pages with catalog items
Users perform searches for catalog items
Users add items to shopping carts
Users check out

Diagram the application


Show subsystems
Show data flow
List assets
Decompose the Application
Identify trust boundaries.
Identify data flow.
Identify entry points.
Identify privileged code.
Document the security profile.
Trust Boundary
Trust Boundary
Security Profile
Identify Threats
Method #1: Threat lists
Start with laundry list of possible threats
Identify the threats that apply to your app
Method #2: STRIDE
Categorized list of threat types
Identify threats by type/category
Optionally draw threat trees
Root nodes represent attacker's goals
Trees help identify threat conditions
STRIDE
Rank the Threats
DREAD model
Damage potential: How great is the damage if the vulnerability is
exploited?
Reproducibility: How easy is it to reproduce the attack?
Exploitability: How easy is it to launch an attack?
Affected users: As a rough percentage, how many users are
affected?
Discoverability: How easy is it to find the vulnerability?
Threat Modeling Steps – OWASP (Simplified)

● Step 1: Decompose the Application


● Step 2: Determine and Rank Threats
● Step 3: Determine Countermeasures and Mitigation
Threat Modeling Steps - MS SDL
● Defining security
requirements.
● Creating an application
diagram.
● Identifying threats.
● Mitigating threats.
● Validating that threats have
been mitigated.
Threat Modeling - Define
Threat Modeling - Diagram
Diagramming - DFD
Objective: To model an application design as a data flow
diagram to drive threat analysis

Data flow diagrams (DFDs)


Widely used and easily understood graphical representation
Most attacks based on data flowing through an application
or system

Trust boundaries
Elements
Elements

Trust boundaries are points within an application where data flows


from one privilege level to another
Network sockets
External entities and processes with different trust levels
Threat Identification
Objective: To identify threats for each data flow diagram
element in the threat model

Experts: Brainstorming and other informal methods

Experts and Non-Experts: STRIDE threat types


STRIDE by DFD Elements
Mitigation
Objective: To address identified threats to an application design

Approaches to threat mitigation (in order of preference):


Redesign
Use standard mitigations
Use unique mitigations
Accept risk in accordance with policies
Validation
Objective : To help ensure that threat models accurately reflect
application design and potential threats

Validation of the model


Validation of enumerated threats
Validation of mitigations
Validation of assumptions
Advantages
Can be used to find threats to a system early in the development
process
Can be used by both security experts and non-security experts
Can be used to guide other security assessment activities

Disadvantages : Upfront costs (training, software, and setup)


Tools

Cairis
Microsoft Threat Modeling Tool
OWASP Threat Dragon

https://www.microsoft.com/en-us/download/details.aspx?id=49168
Questions
[email protected]

You might also like