Threat Modeling and OWASP Top 10 (2017 rc1)

An Overview of the OWASP Top Ten Web Application Risks
and Threat Modeling Web Applications
THREAT MODELING FOR
WEB APPLICATIONS 
AND OTHER DUTIES AS ASSIGNED…
1

10/19/2017 Mike Tetreault, CISSP, CSSLP, HCISPP
⦿ Who is Mike Tetreault?
● Twenty five years of IT experience
● Technically more, but seventh graders aren’t reliable network consultants..
● Primarily web application development and team leadership, but also includes
network, server, and database administration.
⦿ Security background
● Lifelong interest in physical and data security.
● Security is the one constant across all of my roles.
● Certification Activities
● 2003 – Certified Information Systems Security Professional (CISSP)
● 2009 – Certified Secure Software Lifecycle Professional (CSSLP)
● 2013 – Healthcare Information Security and Privacy Practitioner (HCISPP)
● Regularly participate in Examination and Credential Development Workshops
Introduction
2

⦿ What do I do today?
● Functional IT Manager, Application Security
● Two primary practices:
● Access Enablement
● Web Application Firewall
● Authenticated Reverse Proxy
● Web Application and Code Security
● Static and Dynamic Analysis Tools
● Covers Preventative, Detective, Corrective, and Compensatory
controls
Introduction (cont)
3

⦿ Why focus on web applications?
● We all have them and we all use them
● This is why they have the largest threat profile
⦿ Why are web applications everywhere?
● Quickly installed and updated
● Work across devices and operating systems
⦿ Why is this bad?
● Data is accessible from anywhere
● Clients do some hidden processing
⦿ This is what leads to vulnerabilities
Presentation Overview
4

⦿ Asset
⦿ What we’re trying to protect.
⦿ Threat
⦿ What we’re trying to protect against.
⦿ Vulnerability
⦿ Weakness or gap in our protection efforts.
⦿ Risk
⦿ The intersection of assets, threats, and
vulnerabilities.
Terms
5

Why It Matters
⦿ According to the 2015 Global Information Security Workforce
Study by (ISC)2, 72% of the over 14,000 IT professionals
surveyed believe that application vulnerabilities are the
number one security issue for 2013.
⦿ Heartland Payment Systems suffered a SQL injection attack in
2008 which cost them $170 million, by their own admission.
⦿ Equifax breach of 2017 has been determined to be due to an
unpatched Apached Struts 2 vulnerability.
⦿ Corrective (patching) and Compensatory (Web Application
Firewall) controls could have prevented the attack.
⦿ 2016 “Cost of Data Breach” study by IBM and Ponemon puts
the overall cost of a data breach at $154 to $158 per record.
6

⦿ Started in 2001
⦿ Has tremendous resources available for security
professionals and developers alike
⦿ In the midst of updating their flagship OWASP Top Ten
Most Critical Web Application Security Risks
⦿ RC2 expected any day now
⦿ This presentation is based on RC1, which was
rejected
OWASP - The Open Web Application
Security Project
7

OWASP Top Ten Web Application Security Risks
Injection Sensitive Data Exposure
Broken Authentication and
Session Management
Insufficient Attack
Protection (new)
Cross-Site Scripting (XSS) Cross-Site Request Forgery
Broken Access Control (new)
Using Components With
Known Vulnerabilities
Security Misconfiguration Underprotected APIs (new)
8

⦿ What it is:
● Injection flaws, such as SQL, OS, and LDAP injection occur when
untrusted data is sent to an interpreter as part of a command or
query. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper
authorization.
⦿ What it looks like:
● String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
⦿ How to mitigate:
● Keep untrusted data separate from commands and queries.
● Use a safe API with parameterized inputs.
● Scrub inputs to escape special characters (eg, SQL’s ‘:’ operator).
A1: Injection
9

How Popular is SQL Injection?
10

⦿ What it is:
● Application functions related to authentication and session
management are often not implemented correctly, allowing
attackers to compromise passwords, keys, or session tokens, or to
exploit other implementation flaws to assume other users’ identities.
● http://example.com/saleitems?
jsessionid=2P0OCLPSKHCJUN2JVdest=Hawaii
● Use a single set of strong authentication and session management
controls that has a simple interface for developers.
● Strong efforts should also be made to avoid Cross-Site Scripting (XSS)
flaws which can be used to steal session IDs.
A2: Broken Authentication and Session
Management
11

⦿ What it is:
● XSS flaws occur whenever an application takes untrusted data and
sends it to a web browser without proper validation or escaping.
XSS allows attackers to execute scripts in the victim’s browser
which can hijack user sessions, deface web sites, or redirect the
user to malicious sites.
● page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";
● Properly escape all untrusted (ie, user supplied) data based on the
HTML context (body, attribute, JavaScript, CSS, or URL) that the
data will be placed into.
A3: Cross-Site Scripting (XSS)
12

⦿ What it is:
● Restrictions on what authenticated users are allowed to do are not
properly enforced. Attackers can exploit these flaws to access
unauthorized functionality and/or data, such as access other users’
accounts, view sensitive files, modify other users’ data, change access
rights, etc.
● Valid: http://example.com/app/accountInfo?acct=myacct
● Not Valid: http://example.com/app/accountInfo?acct=notmyacct
● Use per-user or per-session indirect references.
○ This means that the reference is only valid for a single user or session, and
means nothing to a different user or session.
A4: Broken Access Control
13

⦿ What it is:
● Good security requires having a secure configuration defined and
deployed for the application, frameworks, application server, web
server, database server, and platform. Secure settings should be
defined, implemented, and maintained, as defaults are often
insecure. Additionally, software should be kept up to date.
● Maintain a repeatable hardening process that makes it fast and
easy to deploy another environment that is properly locked down.
● Implement a process for keeping abreast of and deploying all new
software updates and patches in a timely manner.
A5: Security Misconfiguration
14

⦿ What it is:
● Many web applications do not properly protect sensitive data.
Attackers may steal or modify such weakly protected data to
conduct credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as encryption at rest
or in transit, as well as special precautions when exchanged with
the browser.
● Encrypt all sensitive data at rest and in transit.
● Use standard algorithms with proper key management.
● Do not store sensitive data unnecessarily.
● Disable autocomplete and caching on pages that collect or display
sensitive information.
A6: Sensitive Data Exposure
15

⦿ What it is:
● Web Applications need to be resilient in the face of attacks. This means that
the confidentiality, integrity, and availability of the data must be maintained in
the face of attack.
● Attacker with OWASP ZAP or SQLMap scans an application to detect its
vulnerabilities and possible exploit them.
● Detect Attacks
○ Commodity scanners stick out. Use this uniqueness to identify them. Look for a high
volume of requests, repeated requests for the same resource, etc.
● Respond to Attacks
● Blocking is the first line of defense, but delaying responses or requiring a captcha is
valid as well.
● Patch Quickly
● If a critical patch can’t be pushed quickly, consider a “virtual patch” instead.
A7: Insufficient Attack Protection
16

⦿ What it is:
● A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included
authentication information, to a vulnerable web application. This allows the attacker
to force the victim’s browser to generate requests the vulnerable application thinks
are legitimate requests from the victim.
● http://example.com/app/transferFunds?
amount=1500&destinationAccount=4673243243
● Embedded link in malicious page: <img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
● Include a unique token, individual to each user or session, in every page as a hidden
field.
○ Verify that this token is returned with every request. If it is not, destroy the session and force
the user to reauthenticate.
● Require an explicit user authentication for high-value transactions.
○ This ensure the user is aware of the activity.
A8: Cross-Site Request Forgery (CSRF)
17

⦿ What it is:
● Components, such as libraries, frameworks, and other software
modules, almost always run with full privileges. If a vulnerable
component is exploited, such an attack can facilitate serious data
loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a
range of possible attacks and impacts.
● Don’t use external, third-part components. It’s not realistic, but it
will work.
● Identify all components and versions you are using. Keep up to
date with both releases by the components maintainers and
identified vulnerabilities on security mailing lists and databases.
A9: Using Components with Known
Vulnerabilities
18

⦿ What it is:
● Many modern web applications use APIs to transmit
commands and data between the users and systems. This
communication can be easily intercepted, analyzed, and
manipulated.
● Ensure secured communication between the clients and
APIs.
● Ensure the parser configuration is hardened against attacks.
● Protect against injection attacks in all forms, not just
browsers.
A10: Underprotected APIs
19

⦿ First, are there any questions about the OWASP
Top Ten vulnerabilities?
⦿ Web applications present a big target
● Broad profile with rich data
⦿ Where do you begin with your security efforts?
⦿ Enter: Threat Modeling!
What now?
20

⦿ A systematic approach for understanding, classifying,
and assigning risk to threats and vulnerabilities
⦿ Security becomes what it should be: A cost/benefit
analysis.
⦿ Based on two different classification schemes:
● STRIDE
○ STRIDE classifies threat
● DREAD
○ DREAD classifies risks
What is Threat Modeling?
21

⦿ The sooner the better.
⦿ Prevention is better than a cure.
When Do You Threat Model?
22
Source: IBM Systems Sciences Institute

⦿ Identify your security objectives
● All security can be characterized as being related to
Confidentiality, Integrity, or Availability.
● An objective can be tied to one or all of those characteristics
⦿ High Level Objective Categories
● Identity
● Financial
● Reputation
● Privacy and Regulatory
● Availability Guarantees
How do you start?
23

⦿ Application Overview
● Understand the Components, Data Flows, and Trust Boundaries.
● UML Use Case diagrams are handy for this.
⦿ Decompose the Application
● Identify the features and modules with security impacts.
● Understand:
○ How data enters the module.
○ How the module validates and processes the data.
○ Where the data flows.
○ How the data is stored.
○ What fundamental decisions and assumptions are made by the module.
⦿ Now that you know what the application looks like, you can
classify its threats using the STRIDE model.
What does the application look like?
24

Decomposing the Application
25
Courtesy of OWASP

Decomposing the Application (cont.)
26
Courtesy of OWASP

Understanding The Threats,
Vulnerabilities, and Mitigations
27
Courtesy of OWASP

⦿ Spoofing
● Users cannot become another user or assume their attributes.
⦿ Tampering
● Applications should never send internal data to users, and should always verify
inputs before storing or processing it.
⦿ Repudiation
● An application needs to be able to prove that authorized activities are initiated by
authenticated users.
⦿ Information Disclosure
● Applications should only store sensitive data if proper controls are in place.
⦿ Denial Of Service
● Large, resource-intensive queries should only be accessible to properly authorized
and authenticated users.
⦿ Elevation of Privileges
● Users should only be able to access information and processing capabilities
appropriate for their role in a system.
STRIDE – Characterizing Known Threats
28

⦿ Each threat is scored on a 1-10 scale, added together, and divided by 5.
⦿ Damage
● If a threat exploit occurs, how much damage will it cause?
⦿ Reproducibility
● How easy is it to reproduce a threat exploit?
⦿ Exploitability
● How difficult are the steps needed to exploit the threat?
⦿ Affected Users
● How many users are affected if a threat is exploited?
⦿ Discoverability
● How easy is it to discover the threat?
● Often set to 10 by default, with the assumption that it will be discovered.
DREAD – Classifying, Quantifying, Comparing,
and Prioritizing Risk
29

⦿ Analyze the DREAD score for each threat
⦿ Understand the remediation for each threat, and what you need
to do with the risk presented by each:
● Acceptance – Not all security is “worth it”
○ You don’t spend $50,000 on security controls for a hot dog cart.
● Avoidance – Just don’t do it
○ Not typically feasible in application development.
● Limitation – Take steps to minimize risk
○ Most common risk management strategy.
○ Example: Disk drives may fail, so we maintain RAID and backups.
● Transference – Let someone else take the risk
○ Outsource common functions that are not a core competency .
○ Purchasing insurance can be an option.
Next Steps
30

⦿ “Awww, man. This is too hard!”
⦿ The less structured approach:
⦿ 1. What are you building or deploying?
⦿ 2. What can go wrong?
⦿ 3. What are you going to do about it?
⦿ 4. Did you do well with steps 1-3?
An Alternative…
31

⦿ “Think like an attacker.”
⦿ Not quite.. “Let’s go through this in a structured
way and find the real problems.”
⦿ “You’re never done threat modeling.”
⦿ “Perfect is the enemy of good.”
⦿ Model -> Identify -> Mitigate -> Validate
⦿ “The way to threat model is…”
⦿ There is no perfect way to threat model!
⦿ What works for you may not work for others.
Traps of Threat Modeling
32

⦿ “Threat modeling is born, not taught.”
⦿ Just like any skill, it is learned.
⦿ Interest helps though.
⦿ “Threat modeling is for specialists.”
⦿ Threat modeling is like version control.
⦿ Every developer understands it, but only a few are
responsible for administering it.
⦿ Starting at the wrong time
⦿ Earlier is almost always better.
Traps of Threat Modeling
33

⦿ Let’s say you have a space station, and it has a highly
exploitable exhaust port… What would its DREAD score
look like?
Other Uses!
34

⦿ Or you have a big invading space ship, and you allow
unauthenticated access to your network (and don’t
have host security)…
Other Uses!
35

⦿ If you run a highly virtualized environment with
potentially hostile VM’s, be sure you monitor 
hosts breaking out of 
the sandbox…
Other Uses!
36

⦿ You maintain a complex, life critical system of
hardware and software, and allow one person 
to develop, 
implement, 
and support the 
application…
Other Uses!
37

⦿ Web Application Firewall (WAF)
⦿ What is it?
⦿ System that filters, monitors, and blocks traffic to
and from a web application
⦿ Why use it?
⦿ Can mitigate every item in the OWASP Top Ten
⦿ Payment Card Industry (PCI) Data Security Standard
(DSS) Section 6.6 requires it.
⦿ Or Application Code Reviews, but why choose?
An Alternative to the Alternative
38

OWASP Top Ten Web Application Security Risks
Injection Sensitive Data Exposure
Broken Authentication and
Session Management
Insufficient Attack
Protection (new)
Cross-Site Scripting (XSS) Cross-Site Request Forgery
Broken Access Control (new)
Using Components With
Known Vulnerabilities
Security Misconfiguration Underprotected APIs (new)
39

⦿ They’re touchy to set up.
⦿ They can be noisy for alerts.
⦿ The lower your tolerance for false positives, the less
meaningful your controls.
⦿ The converse is true as well!
⦿ WAF’s require a specialized skill set to be truly
proficient.
Web Application Firewalls are great,
but…
40

⦿ Email: mike@macrocosmictech.com
⦿ I’m on LinkedIn, and these slides will be too!
⦿ Resources:
● OWASP – The Open Web Application Security Project
○ https://www.owasp.org/
● Threat Modeling, Frank Swiderski and Window Snyder
● Threat Modeling Web Applications, J.D. Meier, Alex Mackman, Blaine
Wastell
● Threat Modeling: Designing for Security, Adam Shostack
● Mailing Lists and other resources:
○ Common Vulnerabilities and Exposures Database - http://cve.mitre.org
○ Microsoft Security Response Center
○ SANS – http://www.sans.org
Questions / Comments / Resources
41

Threat Modeling and OWASP Top 10 (2017 rc1)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Threat Modeling and OWASP Top 10 (2017 rc1)

Similaire à Threat Modeling and OWASP Top 10 (2017 rc1) (20)

Dernier

Dernier (20)

Threat Modeling and OWASP Top 10 (2017 rc1)