Difference between revisions of "Threat Modeling Guide for Web Apps"
(→Identify Potential Threats Using STRIDE) |
|||
| Line 20: | Line 20: | ||
==Identify Potential Threats Using STRIDE== | ==Identify Potential Threats Using STRIDE== | ||
Use the **STRIDE** framework to categorize risks: | Use the **STRIDE** framework to categorize risks: | ||
| − | {| | + | {| border="1" padding="2" width="888px" |
| − | | **Threat** | **Description** | **Example** | | + | | **Threat** || **Description** || **Example** | |
| − | |- | + | |- |
| − | | **Spoofing** | Impersonating an entity | Stolen credentials used to access admin portal | | + | | **Spoofing** || Impersonating an entity || Stolen credentials used to access admin portal |
| − | | **Tampering** | Modifying data | Injection attacks manipulating database entries | | + | |- |
| − | | **Repudiation** | Denying actions | Lack of logging allows attackers to erase footprints | | + | | **Tampering** || Modifying data || Injection attacks manipulating database entries |
| − | | **Information Disclosure** | Exposing sensitive info | Leaked API keys or SQL errors revealing database schema | | + | |- |
| − | | **Denial of Service** | Disrupting service | DDoS attacks flooding the application | | + | | **Repudiation** || Denying actions || Lack of logging allows attackers to erase footprints | |
| − | | **Elevation of Privilege** | Gaining higher access | Bypassing access controls to become an admin | | + | | **Information Disclosure** || Exposing sensitive info | Leaked API keys or SQL errors revealing database schema |
| + | |- | ||
| + | | **Denial of Service** || Disrupting service || DDoS attacks flooding the application | ||
| + | |- | ||
| + | | **Elevation of Privilege** || Gaining higher access || Bypassing access controls to become an admin | ||
| + | |- | ||
|} | |} | ||
| − | + | ===Recommended Approach=== | |
- **Map attack vectors** for each STRIDE category. | - **Map attack vectors** for each STRIDE category. | ||
- **Assess impact** of each threat scenario. | - **Assess impact** of each threat scenario. | ||
| Line 37: | Line 42: | ||
- OWASP ZAP | - OWASP ZAP | ||
- Burp Suite | - Burp Suite | ||
| − | - Mitre ATT&CK framework | + | - Mitre ATT&CK framework |
| − | |||
==Define Mitigation Strategies== | ==Define Mitigation Strategies== | ||
Revision as of 17:44, 15 June 2025
Contents
Full Title
Threat Modeling Guide for Web Applications
Web applications are a prime target for security threats. A solid **threat modeling** process helps identify vulnerabilities early, ensuring your app remains secure. This guide follows industry best practices.
---
Understand the Application Architecture
Before modeling threats, map out the web application’s architecture: - Identify **entry points** (e.g., login pages, APIs). - Define **trust boundaries** (e.g., database vs. front-end). - Document **components** (e.g., authentication systems, third-party integrations).
Tools
- Diagrams.net (formerly draw.io) - OWASP Threat Dragon - Microsoft Threat Modeling Tool
---
Identify Potential Threats Using STRIDE
Use the **STRIDE** framework to categorize risks:
| **Threat** | **Description** | |||
| **Spoofing** | Impersonating an entity | Stolen credentials used to access admin portal | ||
| **Tampering** | Modifying data | Injection attacks manipulating database entries | ||
| **Repudiation** | Denying actions | **Information Disclosure** | Leaked API keys or SQL errors revealing database schema | |
| **Denial of Service** | Disrupting service | DDoS attacks flooding the application | ||
| **Elevation of Privilege** | Gaining higher access | Bypassing access controls to become an admin |
Recommended Approach
- **Map attack vectors** for each STRIDE category. - **Assess impact** of each threat scenario.
Tools
- OWASP ZAP - Burp Suite - Mitre ATT&CK framework
Define Mitigation Strategies
To defend against threats: - **Authentication security:** Use **OAuth 2.1** or **FIDO2** for identity management. - **Input validation:** Implement **strict sanitization** to prevent SQL Injection & XSS. - **Encryption & Secure Storage:** Protect data at rest with AES-256 and in transit using TLS 1.3. - **Logging & Monitoring:** Use **SIEM tools** (Splunk, ELK) to detect suspicious behavior. - **Rate Limiting & Firewalls:** Deploy **WAF** (Cloudflare, AWS Shield) to prevent DDoS.
Tools
- OWASP Dependency Check - SIEM (Splunk, Elastic Security) - Web Application Firewalls (ModSecurity, AWS WAF)
---
Validate & Iterate the Model
Threat modeling is **not a one-time process**—it should evolve as the application grows. - Conduct **regular security audits.** - Perform **penetration testing** (ethical hacking). - Update **threat models** when infrastructure changes occur.
Recommended Practices
- Integrate threat modeling into **DevSecOps workflows**.
- Use **CI/CD pipelines** for automated security checks.
- Encourage **security awareness** among developers.
