This document discusses threat modeling for software applications. It covers the key stages of threat modeling including decomposing the application, determining and ranking threats using STRIDE, and determining countermeasures. Specific topics covered include threat modeling approaches, data flow diagrams, trust levels, the STRIDE framework for analyzing spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. It also discusses mobile threat modeling and provides an example threat analysis of a student results portal application.

1. Threat Modeling
-Sunil

2. Agenda
Introduction
Threat Modeling Overview
Different Stages of Threat Modeling
STRIDE
DREAD
Mobile Threat Modeling
Conclusion

3. What is the use of threat modeling?
The main aim of the threat modeling is to identify the
import assets/functionalities of the application and
to protect them.

4. What is a threat?

5. What is a Vulnerability?
• Vulnerability is nothing but weakness in the system which will aid the
attacker in successful execution/exploitation of the threat.
Example: Suppose you have a web server with low bandwidth connection. Where the
threat is that your server could be taken offline, a pothential vulnerability is that you
have low bandwidth and could be a prey for a DoS attack. A paper is vulnerable to
fire.
• Risk: Risk is nothing but threat times vulnerability. That means the
potential loss/damage of an assest as result of a threat exploitation
using vulnerability.

6. Threat Modeling
● Analyzing the security application
● Allows to understand the entry points to the application and their
associated threats
● Not an approach to review code
● Threat Modeling will be done in design phase of SDLC.
● Threat modeling in SDLC will ensure the security builtin from the
very beginning of the application development.

7. Approaches to threat modeling
Attacker-centric
Software-centric STRIDE is a Software-centric approach
Asset-centric

8. Threat Modeling High Level Overview
Kick-off
•Have the overview of the project
•Get the TLDS and PRDS
•Identify the assets
Identify Use
cases
•Draw level-0 diagram analyze (STRIDE)
•Document the findings
•Have a meeting with architect to review
•Identify uses cases for level-1
Level-1
•Draw level-1 diagram analyze (STRIDE)
•Document the findings
•Have a meeting with architect to review
•Repeat the above procedure depending upon the project complexity

9. Threat Modeling High Level Overview
ASF
• Prepare the checklist and send to the product team
• Analyze the document
• Document the findings
Report
• Prepare the final report
• Submit it to the product team
• Explain the findings to the product team

10. Three Stages of Threat Modeling
The threat modeling process can be decomposed into 3
high level steps:
➔ Decompose the Application
➔ Determine and rank threats
➔ Determine countermeasures and mitigation

11. Decompose the Application
 Threat Model Information
 Data Flow Diagrams
 Assets
 External Dependencies
 Entry Points
 Trust Levels

12. Data Flow Diagrams

13. Determine and Rank Threats (STRIDE)
Spoofing
• Property 
Authentication
• Impersonating
something or
someone else
Tampering
• Integrity
• Modifying
data or code
Repudiation
• Non-
Repudiation
• Claiming to
have not
performed an
action
Information
Disclosure
• Confidentiality
• Exposing info
to
unauthorized
Denial of
Service
• Availability
• Deny or
degrade
service to
users
Elevation of
Privilege
• Authorization
• Gain
capabilities
without proper
authorization

14. Sample Problem

15. Student Results Portal
 You need to perform threat analysis on the web application which
manages the students marks.
 You have three users Administrator, Teacher and Student.
 The users should login to the application and perform their
respective tasks as follows:
 Administrator is the user who will maintain the application and does not perform
any other actions.
 Teacher can view, enter and modify the students marks
 Student can give his register number and view the marks
 Perform Threat modeling on the application by making an initial
assumption that non of the security features exist in the
application.

16. Microsoft SDL Threat Modeling Tool

17. Use Cases
 Entire Architecture
 Administrator Use Case
 Teacher Use Case
 Authentication Use Case
 Registering Use Case
 Entering Marks Use Case
 Displaying Marks Use Case etc.

18. Sample Use case (Displaying Marks)

19. Trust Levels

20. STRIDE Matrix
Spoofing Tampering Repudiation Info Disclosure Denial of
Service
Elevation of
Privilege
2.teacher ✓ ✓
3.student ✓ ✓
4.firewall ✓ ✓ ✓ ✓ ✓ ✓
5.App Server ✓ ✓ ✓ ✓ ✓ ✓
6.Http req ✓ ✓ ✓
7. Http req ✓ ✓ ✓
8.response ✓ ✓
9.JDBC req ✓ ✓ ✓
10. respon ✓ ✓ ✓
11.http req ✓ ✓ ✓
12.res ✓ ✓ ✓
13.res ✓ ✓ ✓
14.Database ✓ ✓ ✓

21. Threat Analysis

22. Scoring: DREAD
DREAD is a risk ranking model
D  Damage Potential
R  Reproducibility
E  Exploitability
A  Affected users
D  Discoverability

23. Example
Threat: Malicious users can view and modify marks.
Damage potential: Threat to reputation :8
Reproducibility: Fully reproducible:10
Exploitability: Require to be on the same subnet or have compromised a router:7
Affected users: Affects all users:10
Discoverability: Can be found out easily:10
Overall DREAD score: (8+10+7+10+10) / 5 = 9

24. Mitigation
STRIDE Threat & Mitigation Techniques List
Threat Type Mitigation Techniques
Spoofing Identity
1.Appropriate authentication
2.Protect secret data
Tampering with data
1.Appropriate authorization
2.Hashes
3.MACs
4.Digital signatures
5.Tamper resistant protocols
Repudiation
1.Digital signatures
2.Timestamps
3.Audit trails
Information Disclosure
1.Authorization
2.Privacy-enhanced protocols
3.Encryption
4.Protect secrets
5.Don't store secrets
Denial of Service
1.Appropriate authentication
2.Appropriate authorization
3.Filtering
4.Throttling
5.Quality of service
Elevation of privilege 1.Run with least privilege

25. Security Controls (ASF)
➢ Authentication
➢ Authorization
➢ Cookie Management
➢ Data/Input Validation
➢ Error Handling/Information Leakage
➢ Logging/Auditing
➢ Cryptography
➢ Session Management

26. Mobile Threat Modeling

27. Mobile Threat Model
•Improper session
handling
•Social Engineering
•Malicious QR Codes
•Untrusted NFC Tag or
peers
•Malicious application
•Weak Authorization
Spoofing
• Modifying local
data
• Carrier Network
Breach
• Insecure Wi-Fi
Network
Tampering
• Missing Device
• Toll Fraud
• Malware
• Client Side
Injection
Repudiation
• Malware
• Lost Device
• Reverse
Engineering
• Backend Breach
Information
Disclosure
•Crashing Apps
•Push Notification
Flooding
•Excessive API usage
•DDoS
Denial of
Service
• Sandbox escape
• Flawed Authentication
• Weak Authorization
• Compromised credentials
•Make Unauthorized
purchases
•Push Apps Remotely
• Compromised Device
•Rooted/JailBroken
•RootKitsElevation of
Privilege

28. Conclusion
 Implement Threat Modeling in SDLC
 Threat Modeling cuts down the cost of application
development as it identifies the issues during the
design phase.
 Makes the analysis simple because you can reuse the
DFD’s for future analysis.

29. Credits
https://www.owasp.org/index.php/Application_Threat_Modeling
https://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx
http://www.thebadchemicals.com/?p=17
http://en.wikipedia.org/wiki/Threat_model
http://www.someecards.com/
http://www.eugenemdavis.com/whats-difference-between-threat-and-
vulnerability
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_
Project_-_Mobile_Threat_Model

30. THANK YOU