Understanding Application Threat Modelling & Architecture - 99% of Application has at least one vulnerability

1. Security Architecture and
Threat Modelling
Nilanjan De

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

3. Security Architecture and
SDLC

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  $$

9. Enabling S-SDLC
Source
Repository
Build
Management
System
Static Analysis
Tool
Team City
Jenkins
Hudson
Bamboo
TFS
SVN
GIT
Etc.
Developers
Team Leaders /
Security team
Production

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

14. Threat Modelling

16. Threat Modelling

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

23. The Threat Modeling Process
Identify assets
Document architecture
Decompose application
Identify threats
Document threats
Rate threats
1
2
3
4
5
6

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

26. Example
Bob
Alice
Bill
Asset #4
Asset #1 Asset #2 Asset #3
Asset #5 Asset #6
IIS ASP.NET
Web Server
Login
State
Main
Database Server
Firewall

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?

28. Example
Bob
Alice
Bill
IIS ASP.NET
Web Server Database Server
Trust
Forms Authentication URL Authorization
DPAPI Windows Authentication
Firewall
Login
State
Main

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

39. Castle
Service
Local
User
Castle Config
Feedback
Join/Leave
Castle
Remote
Castle
A Real Context Diagram

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

46. End exercise

47.  Uncover Security Design Flaws Using the STRIDE Approach
http://msdn.microsoft.com/msdnmag/issues/06/11/ThreatModeling/default.asp
x
 http://msdn.microsoft.com/en-us/magazine/cc700352.aspx
 http://msdn.microsoft.com/en-us/magazine/2009.01.securitybriefs.aspx
 http://msdn.microsoft.com/en-us/security/cc448120.aspx
References

48. Thank You!!

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