Download as PDF, PPTX
![Some of the commonly used
frameworks
STRIDE
● Spoofing
● Tampering
● Repudiation
● Information disclosure
● Denial of service
● Elevation of privilege
DREAD
● Subjective Rating based on
5 Qs of each threats
● Categories:
○ Damage [potential]
○ Reproducibility
○ Exploitability
○ Affected users
○ Discoverability
PASTA
● Process for Attack
Simulation & Threat
Analysis
● Risk Centric
9](https://image.slidesharecdn.com/finalthreatmodelingowasp-210319194038/85/OWASP-based-Threat-Modeling-Framework-9-320.jpg)
Uploaded byChaitanya Bhatt
OWASP based Threat Modeling Framework
The document presents a comprehensive overview of threat modeling within an agile environment, emphasizing the importance of early threat identification to enhance application security. It introduces the P-S-C model, which is grounded in company-specific infosec policies and provides a systematic approach for identifying and mitigating threats. Key takeaways highlight the necessity of a circular, feedback-driven threat modeling process that adapts to evolving threat landscapes while facilitating developer engagement.
More Related Content
![[DevSecOps Live] DevSecOps: Challenges and Opportunities](https://cdn.slidesharecdn.com/ss_thumbnails/20200316dsochallengesopportunities-200416111818-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to OWASP based Threat Modeling Framework
OWASP based Threat Modeling Framework
- 1. OWASP Based Threat Modeling Creating afeedback model in an agile environment
- 2. Hello! I am ChaitanyaBhatt ❏ AppSec Engineer at eBay ❏ MS in Computer Engineering, GIAC-JAVA certified ❏ Threat modeling at eBay, Autodesk, Symantec ❏ Coffee Enthusiast 2
- 3. Agenda 3 ● Conventional threatmodeling ● Threat Modeling Frameworks ● Relevance ● Introduction to the P-S-C Model ● Implementing a P-S-C Threat Model ● The missing piece ● Benefits to the approach ● Key takeaways
- 4. Threat Modeling What isthreat modeling? Why do we need threat modeling?
- 5. “Threat modeling isan art of foreseeing the threats associated with an application and getting them fixed during the early stages 5
- 6.
- 7. Agile Secure-SDLC 7 Requirement Release &Post Release Design Verify Develop DAST Pentest Vulnerability Scanner Bug Bounty Security Training Security Guidelines Threat modeling SAST OAST Agile SSDLC Process
- 8.
- 9. Some of thecommonly used frameworks STRIDE ● Spoofing ● Tampering ● Repudiation ● Information disclosure ● Denial of service ● Elevation of privilege DREAD ● Subjective Rating based on 5 Qs of each threats ● Categories: ○ Damage [potential] ○ Reproducibility ○ Exploitability ○ Affected users ○ Discoverability PASTA ● Process for Attack Simulation & Threat Analysis ● Risk Centric 9
- 10. Relevance ● The Changing Landscape ●Changing attack scenarios/vectors ● Overlapping threat categories ● Real life vs Theoretical 10
- 11.
- 12. 12 Company Policy The foundationof this model is based on company’s InfoSec policy which lays down the Security guidelines based on company’s threat posture 3 Security Standards The Security Standard is built on top of the company’s InfoSec policies which focuses on how to achieve the InfoSec goals. The Security Standards are mitigation specific based on OWASP standards 2 Security Controls The Security Control is the exact recommendation for an identified Threat provided to the product teams based on the applicable security standard. The controls can be strict for some of the critical flows 1 Building blocks
- 13. 13 Company Policy Access ControlPolicy 3 Security Standards Authorization 2 Security Controls ● Stricter Scopes ● Least Privilege access ● Revoking access after usage 1 Building blocks
- 14. Security Standards 14 RL AN Authentication Anti- Automation AZAuthorization BR Browser Security BL Business Logic Abuse C Compliance CM Configuration Management CR Cryptographic Controls DM Data Management I Input Validation/Manipulation L Logging KV Known Vulnerability
- 15. ● Evaluate Riskbased on Policy-Standards- Control ● Create Recommendations ● Apply PSC based on the identified scenarios ● Classify mitigations based on the Threats identified ● Identify entry points ● Identify exit points ● Identify trust boundaries ● Divide & Conquer ● Define the scope ● Identify critical actor, assets and flows ● Discover corner/edge cases ● Discover upstream & downstream services. ● Collect requirement document along with UMLs and Data Flow diagram ● Gather information about Data Classification, Dev language/platform, etc. ● Understand the objective of the app 15 Gather requirements and onboarding information from product teams Requirements gathering & Onboarding Create recommendation based on PSC & Risk evaluated Recommendation/Controls Break application /service into small segments Decompose Apply Policy and Standards Apply PSC Identify the critical assets and flows based on the documentation Identify & Discover Process
- 16. 16 Sample Use Case LibraryManagement System
- 17. Requirement Gathering andOnboarding 17 ● The Library Management System aims to give access while managing the resources of a library ● Actors utilizing this system will be library members, regular users and admin ● The highest data handled by the portal will be PCI data ● The portal accepts membership fees ● The portal will be internet facing ● The portal is built on NodeJS express framework and HTML5, CSS3 ● MongoDB is the default database for the portal
- 18. 18 Admin Member User (Non Member) Login Check Inventory Check Status ReturnBook Issue Book Send Reminder Login Pay membership fee Register Renew Membership Add/ Remove Inventory Update Payment
- 19. 19 Users (Non Members) Admin Members Web Servlet Login Process College Mgmt Sys CollegeDB L o g i n r e q u e s t Login Response Pages Request Page Render Page LMS DB V a l i d a t i o n R e s p o n s e V a l i d a t e C r e d e n t i a l s Authenticate User Authentication Response Validation Response Validating College Affiliation Lo gin req ue st Login Response Registrat ion Process Payment Process Payment DB Verify and process Payment Payment Confirmation Request Page Render Page Reg Request Reg Response A d d u s e r t o D B A d d e d u s e r t o D B REGISTRATION LOGIN
- 20. Applying Policy -Standard - Control 20 Admin Member Sign in Page Login Service Home Page Admin Page Auth DB Payment DB Member Status Service Membership Page Log College DB AA AN AZ I BR L D D D CR CM Policy Infosec Anti Automation policy Standard Anti Automation (AA) Control ● Limit the Sign in Attempts (5) ● Challenge user with Captcha Policy Infosec Browser security policy Standard Browser Security (BR) Control ● Implement CSP policies with know script allowed policy ● Implement anti-CSRF protection ● Implement SRI for external JS Policy Infosec Logging policy Standard Logging (L) Control ● Mask sensitive information ● Log all sign in events CM KV KV CM CM CM CR CR
- 21. Balancing the Risk 21 OWASPRISK RATING I M P A C T HIGH Medium High Critical MEDIUM Low Medium High LOW Note Low Medium LOW MEDIUM HIGH LIKELIHOOD
- 22. Use case 22 Backend DB INTERNET AZD Frontend PHASE - I PHASE - II Authorization IDOR RISK: HIGH RISK: CRITICAL
- 23. Balancing the Risk 23 OWASPRISK RATING I M P A C T HIGH High Critical Critical MEDIUM Medium High Critical LOW Low Medium High LOW MEDIUM HIGH LIKELIHOOD HIGH E X I R S I T S I K N G MEDIUM LOW
- 24. Q. How issuccess measured in a program ? Q. What are the 10 biggest threats in your organization ? Q. What are the 5 products which posses maximum risks Q. How do you prioritize threat modeling requests ? Q. How do you handle Threat Modeling request for incremental changes ? 24
- 25.
- 26. The missing piece 26 ThreatSurfing Requirements gathering & Onboarding Apply Recommendation Decompose the application Apply Policy-Standard- Control Identify & Discover Threat Surfing Store & Analyze
- 27. The missing piece 27 Requirement Release& Post Release Design Verify Develop DAST Pentest Vulnerability Scanner Bug Bounty Security Training Security Guidelines Threat modeling SAST OAST Feedback Feedback Feedback
- 28. 28 Onboarding Portal Database Product Teams Ticketing System ThreatModeling Portal Threat Modeling Engine CISO Auditor Security Engineers Threat Surfing Architecture P-S-C Model
- 29. Onboarding new application 29 Source:Based on Test Data
- 30. Baselining the threatlandscape 30 Source: Based on Test Data Security Standards
- 31. Agile: Relevant toiterative development methodology Update : Caters to the changing threat landscape for an existing model Mitigation centric : Focuses on Mitigation rather than attacks Incremental changes : Handles Incremental changes a lot easier Developer Friendly : Makes it easier for developers to understand the outcomes Aligns with Organizational Goals : The P-S-C Model is built on top of company’s infosec policy. Visibility : Better exposure to upstream and downstream services Benefits 31
- 32. Key Takeaways ● Acircular process doesn't necessarily make it Agile. 32 ● Simply joining the first and last ends of SSDLC process won’t help us keep up with the pace. ● SSDLC needs to create feedback for iterative agile approach
- 33. Key Takeaways 33 ● Focuson OWASP Top 10 mitigations Rather than focusing on OWASP TOP 10 vulnerabilities we should be focusing on OWASP TOP 10 mitigation to connect with the developers
- 34. Key Takeaways ● ThreatModeling can be the brain of an S-SDLC process which yields better visibility through Threat Surfing. 34 ● Good to have a record for every Threat model performed rather than a one time document to accommodate agile ● Threat Surfing can pull information from all stages of SSDLC process to produce intelligent analysis of risk and help in foreseeing the threats in a very earlier stage. ● Helps in maintaining a record of residual risk
- 35. Key Takeaways ● AdaptThreat modeling Framework that is best suited to your organization and your customers 35 Easy to adapt and modify PSC Model to your organizational needs
- 36. Thanks! Any questions? You canfind me at: ● @iamChaitanya30 ● cbhatt@ebay.com 36