2. Average 35
No of vulnerabilities in a
website
52%of data
breaches happen through Web
Applications
of Application
has atleast one
vulnerability
41
High
3
3
5
9
Mediu
m
Low
The Scorecard
90% of hacking incidents are not
reported
99%
82% of web applications have at
least 1 High/Critical Vulnerability
Business Logic Flaws are the most
neglected vulnerabilities
Source: IViZ blog
4. USER AGENTS
User Agent / Client.
Browser, BOT,
Program Sends
Requests like GET,
POST, HEAD, PUT,
DELETE
WEB SERVERS
● Web Server listens for requests
● Has interpreters to understand
PHP/ASP.net
● Talks to the database
● Has TCP ports in listening mode
Database Server
MySQL, MSSQL, Oracle
3 Tier – Web App Architecture
5. Web App Architecture – Data View
Web
Client Data Store
Web Server
Trusted
Code
Running on
server
Web
Service
Un-trusted Input
hitting the server
from the client, data
stores, web
services.
6. Would you trust the code?
Operating System and Shell
Web Server + Interpreter
(PHP/ASP.net)
Trusted Code
7. Traditional SDLC
It’s too late!!
We won’t meet our security standards..
Production
Deadline
Development + QA
Pen Testing
189 Vulnerabilities
Security is taken care of only at the end of the SDLC
8. Secure SDLC
Production
Deadline
Development + QA + Security
Pen Testing
12 Vulnerabilities
Security is implemented during the SW development.
• We can achieve application security
• We save development time $$
10. Cost to find/fix a
defect during
integration/system
test is 15-90 times
higher than at
design/coding
Time &
Cost
Code Inspection
Integration Testing
System TestingStatic analysis tools find
defects and design flaws
“in phase”
Unit Testing
Design Coding QA Production
Scan sources with checkmarx
Scan
binaries
SAST vs. DAST
11. SAST vs. DAST
Dynamic Application Security Testing (DAST)
- Can be performed only at the end of dev.
- More layers covered
- Not compete coverage (it is random).
- Results not shown in the code
Static Application Security Testing (SAST)
- Can be performed from the beginning of the SDLC
- Covers only the application code
- Covers all the application code
- Results are shown inside the code
- Has more false positive results
11
12. SAST vs. DAST
So what is better, DAST or SAST?
For good security both SAST and DAST are
necessary and complete each other.
If you have SAST you will get better quality results
from the DAST service
12
13. SAST Scanning
SAST vendors scan binaries
- Need compilation environment
- Need compliable code.. have to wait
SAST vendors scanning pure source code
- Uses the virtual compiler technology
- No need for compilation environment
- Can scan from day one
- Scan takes longer
System is more flexible can customize the system for
less FP results.
13
17. Common Types of Attack
Connection Fails
Organizational
Attacks
Restricted Data
Accidental Breaches
in Security
Automated
Attacks
Hackers
Viruses,
Trojan Horses,
and Worms
Denial of
Service (DoS)
DoS
18. Types of Threats
Spoofed packets, etc.
Buffer overflows, illicit paths, etc.
SQL injection, XSS, input tampering, etc.
Network Host Application
Threats against
the network
Threats against the host
Threats against the application
19. Threats Against the Network
Threat Examples
Information gathering Port scanning
Using trace routing to detect network topologies
Using broadcast requests to enumerate subnet
hosts
Eavesdropping Using packet sniffers to steal passwords
Denial of service
(DoS)
SYN floods
ICMP echo request floods
Malformed packets
Spoofing Packets with spoofed source addresses
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh15.asp?
frame=true#c15618429_004
20. Threats Against the Host
Threat Examples
Arbitrary code execution Buffer overflows in ISAPI DLLs (e.g., MS01-033)
Directory traversal attacks (MS00-078)
File disclosure Malformed HTR requests (MS01-031)
Virtualized UNC share vulnerability (MS00-019)
Denial of service (DoS) Malformed SMTP requests (MS02-012)
Malformed WebDAV requests (MS01-016)
Malformed URLs (MS01-012)
Brute-force file uploads
Unauthorized access Resources with insufficiently restrictive ACLs
Spoofing with stolen login credentials
Exploitation of open
ports and protocols
Using NetBIOS and SMB to enumerate hosts
Connecting remotely to SQL Server
21. Threats Against the Application
Threat Examples
SQL injection Including a DROP TABLE command in text typed
into an input field
Cross-site scripting Using malicious client-side script to steal cookies
Hidden-field
tampering
Maliciously changing the value of a hidden field
Eavesdropping Using a packet sniffer to steal passwords and
cookies from traffic on unencrypted connections
Session hijacking Using a stolen session ID cookie to access
someone else's session state
Identity spoofing Using a stolen forms authentication cookie to pose
as another user
Information
disclosure
Allowing client to see a stack trace when an
unhandled exception occurs
22. Threat Modeling
Structured approach to identifying, quantifying, and
addressing threats
Essential part of SDLC process
24. Identifying Assets
What is it that you want to protect?
Private data (e.g., customer list)
Proprietary data (e.g., intellectual property)
Potentially injurious data (e.g., credit card numbers, decryption keys)
These also count as "assets"
Integrity of back-end databases
Integrity of the Web pages (no defacement)
Integrity of other machines on the network
Availability of the application
25. Documenting Architecture
Define what the app 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
27. Decomposing the App
Refine the architecture diagram
Show authentication mechanisms
Show authorization mechanisms
Show technologies
Diagram trust boundaries
Identify entry points
Begin to think like an attacker
Where are my vulnerabilities?
What am I going to do about them?
29. Identifying 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
30. STRIDE
S
T
R
I
D
Tampering
Repudiation
Information disclosure
Denial of service
Can an attacker gain access using a false identity?
Can an attacker modify data as it flows through the application?
If an attacker denies doing something, can we prove he did it?
Can an attacker gain access to private or potentially injurious data?
Can an attacker crash or reduce the availability of the system?
E Elevation of privilege
Can an attacker assume the identity of a privileged user?
Spoofing
31. Documenting Threats
Theft of Auth Cookies by Eavesdropping on Connection
Threat target Connections between browsers and Web server
Risk
Attack techniques Attacker uses sniffer to monitor traffic
Countermeasures Use SSL/TLS to encrypt traffic
Document threats using a template
Theft of Auth Cookies via Cross-Site Scripting
Threat target Vulnerable application code
Risk
Attack techniques Attacker sends e-mail with malicious link to users
Countermeasures Validate input; HTML-encode output
32. Rating Threats
Simple model
DREAD model
Greater granularization of threat potential
Rates (prioritizes) each threat on scale of 1-15
Developed and widely used by Microsoft
Risk = Probability * Damage Potential
1-10 Scale
1 = Least probable
10 = Most probable
1-10 Scale
1 = Least damage
10 = Most damage
33. DREAD
D
R
E
A
D
Reproducibility
Exploitability
Affected users
Discoverability
What are the consequences of a successful exploit?
Would an exploit work every time or only under certain circumstances?
How skilled must an attacker be to exploit the vulnerability?
How many users would be affected by a successful exploit?
How likely is it that an attacker will know the vulnerability exists?
Damage potential
34. Example
Threat D R E A D Sum
Auth cookie theft (eavesdropping) 3 2 3 2 3 13
Auth cookie theft (XSS) 3 2 2 2 3 12
Potential for damage is high
(spoofed identities, etc.)
Cookie can be stolen any time, but is only
useful until expired
Anybody can run a packet sniffer; XSS
attacks require moderate skill
All users could be affected, but in reality
most won't click malicious links
Easy to discover: just type a <script> block
into a field
Prioritized
Risks
35. Produce software that’s secure by design
Improve designs the same way we’ve improved code
Because attackers think differently
Creator blindness/new perspective
Why Threat Model
36. Diagram Elements - Examples
•People
•Other systems
•Microsoft.com
•etc…
•Function call
•Network traffic
•Etc.…
•DLLs
•EXEs
•Components
•Services
•Web Services
•Assemblies
•etc…
•Database
•File
•Registry
•Shared
Memory
•Queue/Stack
•etc.…
External
entity
Process Data
Flow
Data Store
Trust Boundary
•Process boundary
•File system
37. Add trust boundaries that intersect data flows
Points/surfaces where an attacker can interject
Machine boundaries, privilege boundaries, integrity
boundaries are examples of trust boundaries
Threads in a native process are often inside a trust
boundary, because they share the same rights and access
Processes talking across a network always have a trust
boundary
Diagrams: Trust Boundaries
38. Context Diagram
Very high-level; entire component / product / system
Level 1 Diagram
High level; single feature / scenario
Level 2 Diagram
Low level; detailed sub-components of features
Level 3 Diagram
More detailed
Rare to need more layers, except in huge projects or when you’re drawing
more trust boundaries
Diagram layers
40. Castle
Service
Explorer
(or rundll32)
SSDP SSDP
Remote
Castle
Service
Registry
LSA
SAM
Local User
Shacct
Get acct info
Feedback
Manage
Castle Join, leave,
Set users props
Set acct info
Read
Castle info
Set psswd
Set acct
info
Feedback
Get machine
password
Cache Castle
info
Query users props
Query other
Castle info
Publish this
Castle info
Manage
Castle
Get acct
info
Get version
info
Set version
info
1 2
3
4
5
6
7
8
9
10
A Real DFD
41. Understanding the threats
Threat Property
Violated
Definition Example
Spoofing Authentication Impersonating
something or
someone else.
Pretending to be any of billg, xbox.com or a
system update
Tampering Integrity Modifying data or
code
Modifying a game config file on disk, or a
packet as it traverses the network
Repudiation Non-repudiation Claiming to have not
performed an action
“I didn’t cheat!”
Information
Disclosure
Confidentiality Exposing information
to someone not
authorized to see it
Reading key material from an app
Denial of Service Availability Deny or degrade
service to users
Crashing the web site, sending a packet and
absorbing seconds of CPU time, or routing
packets into a black hole
Elevation of Privilege Authorization Gain capabilities
without proper
authorization
Allowing a remote internet user to run
commands is the classic example, but running
kernel code from lower trust levels is also EoP
42. Different threats affect each type of element
Process
Data Store
S T R I D E
Element
Dataflow
External Entity
43. Castle
Service
Explorer
(or rundll32)
SSDP SSDP
Remote
Castle
Service
Registry
LSA
SAM
Local User
Shacct
Get acct info
Feedback
Manage
Castle Join, leave,
Set users props
Set acct info
Read
Castle info
Set psswd
Set acct
info
Feedback
Get machine
password
Cache Castle
info
Query users props
Query other
Castle info
Publish this
Castle info
Manage
Castle
Get acct
info
Get version
info
Set version
info
1 2
3
4
5
6
7
8
9
10
A Real Level-0 DFD (Castle)
TID
TID
TID
TID
STRIDE
STRIDE
Etc…
44. Address each threat
Four ways to address threats:
Redesign to eliminate
Apply standard mitigations
Invent new mitigations
Riskier
Accept vulnerability in design
Address each threat!
Mitigate
45. Validate the whole TM
Does diagram match final code?
Are threats enumerated?
Minimum: STRIDE per element that touches a trust boundary
Has Test reviewed the model?
Created appropriate test plans
Tester approach often finds issues with TM, or details
Is each threat mitigated?
Are mitigations done right
Validating Threat Models
49. Something to think about
Password analysis from the rockyou.com data revealed
The most common password was; 123456
30% passwords were less than 6 characters
60% passwords were a limited set of alphanumeric (A-Z,
a-z, 0-9) characters
23,000 passwords were set to; rockyou