Rapid Threat Model Prototyping methodology
Download as PPTX, PDF3 likes590 views
The document outlines the challenges and solutions in integrating rapid prototyping into the threat modeling process, particularly in fast-paced environments like DevOps. It critiques traditional threat modeling methods for being slow and inconsistent, and proposes a streamlined approach that emphasizes quick identification of threats and collaboration among stakeholders. The proposed methodology includes using prototyping techniques to facilitate communication and develop a more efficient threat modeling practice adaptable to changing requirements.
Rapid Threat Model Prototyping methodology
- 1. BRINGING RAPID PROTOTYPING TO THE THREAT MODEL PROCESS GEOFF HILL TUTAMANTIC OR... WHAT I HAVE DONE TO MAKE MY THREAT MODELLING LIFE EASIER
- 2. LICENSE FOR USE This work is licensed under the Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc- sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode
- 3. WHO IS THIS GUY?!?
- 4. DEVELOPED A… • fair-value options model in NYC commodities floor in the early 90s
- 5. RAN AROUND … • the world, being a developer in mid-late 90s Will code for food
- 6. STARTED WITH… • Microsoft in 2002, jumped into appSec right away DEVELOPED A… • SDL for ‘customers using Agile’ in 2004 at Microsoft UK
- 7. CREATED A… • project security tracker using modified financial models to score risk
- 8. WORKED WITH… • Visa Europe for 4 years as the only appSec architect
- 9. CURRENTLY WORKING… • at Photobox as the acting global head of appSec
- 10. CREATOR OF… THE TUTAMEN AUTOMATED THREAT MODELLING SYSTEM
- 11. LET’S ROLL… • Steps in traditional TM • Why traditional TM fails in DevOps/CI world • Overview of Agile Architecture • Introduction to rapid prototyping • Introduction to Rapid TM prototyping
- 12. STEPS IN A TRADITIONAL THREAT MODEL PROCESS
- 13. LOTS OF TALKS WITH LOTS OF STAKEHOLDERS
- 14. FIGURING OUT THE UNDERLYING MODEL
- 15. DFDS AND EPHEMERAL TRUST BOUNDARIES
- 18. Add Mitigations and Threats …By consensus?
- 21. MEMORABLE QUOTE • Threat modeling a complex system is a time- consuming exercise and requires a lot of planning and coordination. • Don’t get disheartened; remember that your work group probably includes people with no formal threat modeling training, and they likely have their own workloads and operational priorities outside of the threat modeling effort.
- 22. WHY TRADITIONAL THREAT MODELLING FAILS IN A DEVOPS/CI WORLD • Can’t do it fast enough • More detail than is necessary • Not consistent with terminologies • Can’t plug into a CI pipeline easily
- 23. OVERVIEW OF AGILE ARCHITECTURE • First part • Intentional architecture • Consistency for changing environments • Enabling cross-team design • reduces redundancies
- 24. OVERVIEW OF AGILE ARCHITECTURE • Second part • Emergent design • Organic grown by team • Continuous Integration and Testing steps • Changing requirements will change design
- 25. INTRODUCTION TO RAPID PROTOTYPING • Identify basic requirements • Conceaptual Design • test the prototype and provide feedback • Revise and enhance
- 26. RAPID THREAT MODEL PROTOTYPING - GOAL • Reduce confusing ………back-and-forth talks with the stakeholders • GOAL - Reduce steps in doing threat modelling
- 27. RAPID THREAT MODEL PROTOTYPING - GOAL • quickly identify ELEVATION OF PRIVILEGE threats • Reduce misinterpretation of designs
- 29. RAPID THREAT MODEL PROTOTYPING - GOAL • Build on current INTENTIONAL architecture • Don’t create new DFDs
- 30. RAPID THREAT MODEL PROTOTYPING - GOAL • CONSISTENT data • REPEATABLE data • MEASURABLE data For CI/CD & DevOps
- 31. RAPID THREAT MODEL PROTOTYPING - PURPOSE • Start the conversation • 80/20 rule • Just-enough information • Not comprehensive… initially
- 32. GOOD CANDIDATE FOR AUTOMATION
- 33. AGREE UPON A BASE FRAMEWORK TO COMMUNICATE ISSUES ACROSS GROUPS
- 36. BUILD ON A CURRENT CONTEXT OR PROCESS DIAGRAM • Model Storming to adapt new requirements • No Ack/Nack flows • No data repetition • Save TM data in these diagrams • Run TM through process per diagram change
- 37. WE WILL BE USING THIS • (example is loosely mapped to OSI Layer 6)
- 39. DISCOVER THE ZONES OF TRUST (AKA… NUMBERED TRUST BOUNDARIES) • Finds Elevation of Privilege issues quickly • Data stores == highest
- 40. 0 1 0 2 3
- 41. APPLY ZONE RULES (GUIDELINES TO CALCULATE BASE ATTACKS) • Rules are meant to kickstart analysis process • From Lower to Higher – Elevation of Privilege • From Higher to Lower – Information Disclosure • Intial values on all flows are CIA values • From 0 (or less) to greater than 0 – Spoofing (happens at both ends) • + Repudiation (at target) • Denial of Service happen where 0 (or less) to greater than 0 (flows and target)
- 43. RELATIVE PROBABILITY VALUES (TO DIAGRAM) 0 1 0 2 3 SE SRE SRE SRE SE TID TID TID TID TID TID 2/6 3/6 3/6 3/6 3/6 2/6 3/6 3/6 3/6 3/6 3/6 2/6 3/6 .33 .5 CRUDE WEIGHTING FOR ATTACK PROBABILITY
- 44. DO ZONE MATH TO FIND THREAT IMPACT • biggest differences from lowest to highest are MOST dangerous flows • Perfect for automation! • One-time entry of values • Model dangerous Actors with negative values
- 45. THREAT IMPACT MULTIPLIER 0 1 0 2 3 DANGEROUS? 3/3 3/1 2/1 How do you want to model this role? 3/3 2/1 1.0 2.0 3/1 3.0
- 46. CRUDE RISK VALUES (FACTOR UP BY 10) 0 1 0 2 3 FLOW1 .33 1 2 (((6*.5) +.33)/7)*1= 4.8 (((2*.5) +.33)/3)*2= 8.8 3 (((2*.5) +.33)/3)*3= 13.2 .5 .5 .5 .5 .5 .5 .33 .5 .5
- 47. MAP MITIGATIONS BASED ON ANTI-STRIDE PROPERTIES 0 1 0 2 3 SE SE SE SE SE TID TID TID TID TID TID SE OIDC, OAUTH2 TID SE TLS, CONSTRAIN OIDC, SSH MITIGATIONS CAN BE MAPPED IN A TABLE TO ATTACK ELEMENTS
- 48. MITIGATIONS • Triage on calculated Risk • T-shirt-size on calculated • Send this output to sprint backlog (e.g. Jira)
- 49. THREATS • Generate automated test cases • Send this output to risk register/threat db (e.g.
- 50. ONE-PAGE SECURITY TESTING GUIDE • Spoofing (Authentication) • Elevation of Privilege (Authorization) • Information Disclosure (Sensitive Data) • Tampering (Data validation) • Spoofing (Authentication) • Elevation of Privilege (Authorization) • Information Disclosure (Sensitive Data) CLIENT SERVER ROLES TO USE QUESTIONS TO ASK • God • Authenticated user • Anonymous • Can I READ it? • Can I GUESS it? • Can I CHANGE it?
- 51. SEND THREAT MODEL INFORMATION TO PIPELINE • JSON, XML, CSV… • Any consumable format
- 52. REPORTING • Create human- readable reports from data! • Attach data to release
- 53. SORT OTHER TOOLS TO INGEST TM DATA • Risk tools • dashboards
- 54. • Track issues in deployment versus threats in register
Editor's Notes
- #4: You’re probably thinking, what does this person have that makes him a bloody expert? Well, not much really ;-)
- #10: Talk about the fox guarding the chicken coop!
- #13: Based on lots of personal experience!
- #16: DFD starts off ok
- #17: But starts to look messy
- #18: And ultimately messy, silly and unmaintainable HINT – YOU’RE GOING TO GET IT WRONG
- #21: Finally… getting the model out in time… oh no, it’s the final sprint
- #23: NOT MANY OF THE THREAT MODEL OUTPUTS ARE DIRECTLY MEASURABLE… THEY AREN’T NUMBERS!
- #24: Intentional architecture needed where many changes happen in many environments provides a framework for cross-team design and implementation synchronization reduces the production of redundant and/or conflicting code and designs
- #25: Emergent design Grown incrementally by those who are closest Evolves by constant testing and Continuous Integration steps Design grows in accordance with the currently known requirements
- #29: Why you want to identify Elevation of Privilege threats first… the most dangerous attack step is the C&C step.
- #30: Build on the current Intentional architecture instead of creating additional diagrams to support
- #31: Make inputs and outputs consistent to enable inclusion in an automated CI/CD & DevOps environment
- #32: Remember the purpose of rapid prototyping… to start a conversation, not create a complete in-depth threat and mitigation listing!
- #36: In digital security, non-repudiation means: A service that provides proof of the integrity and origin of data. An authentication that can be said to be genuine with high confidence
- #37: Find a representative context or process diagram with help from the relevant architect/designer Model storming at beginning of sprint – define work items in diagram You don’t need Ack/Nack flows! Same protocol over same communication = same threat vectors! Put in a process to upload the diagram into the DevOps process on each diagram change. The TM will show the differences (lack of data or added metadata)
- #38: This example loosely maps to OSI Layer 6 (presentation layer) Again looking broadly, Layer 7 (application) would be apps inside AWS (example) Equivalent of Layer 5 (session) would be network communication diagram https://searchnetworking.techtarget.com/definition/OSI
- #39: Attack trees are too fiddly and too time consuming for little reward.
- #42: Rules are meant as a kickstart to get you started
- #43: These values are a starting CONVERSATION point, to get discussing going. There is no need to go into detail… keep it lean.
- #44: The values in-and-of-themselves are meaningless, but provide a crude weight for attack probability
- #45: Rules are meant as a kickstart to get you started
- #46: The difference in zones between endpoints provides a crude impact measure. Higher gaps will provide more critical areas of concern.
- #51: This shows a quick guide for functional testers to quickly create security tests by asking some simple questions about data on client and server, and using certain roles to see the data.
- #52: You are sending across the minimum amount of data to get the job done.