Using threat models to control project brief
5 likes1,293 views
The document discusses using threat models to control project scope and manage business requests. It provides information on what threat modeling is, why it is useful, and how to conduct threat modeling. Key points include: - Threat models can help "lock" the project brief and scope by requiring any new features or changes to be evaluated in updated threat models. - Threat models should be set up as the authoritative source of truth about security considerations and implications. - Creating threat models for individual features allows for a tighter analysis of each component's risks and connections between components. - Chaining multiple threat models together can help identify overarching vulnerabilities across the system. - Penetration tests should be used to validate the
Using threat models to control project brief
- 1. Using Threat Models as a way to control the project brief/scope Dinis Cruz, London, 22 March 2017
- 8. DFT + STRIDE
- 9. DFT + STRIDE
- 10. Ask the STRIDE Questions https://www.slideshare.net/chinwhei/7-steps-to-threat-modeling
- 11. Start with paper
- 12. ‘LOCK’ THE BRIEF
- 13. • Key challenge for developers (and project managers) is the constant flow of business changes/requests Use Threat Models to control business
- 14. • Key challenge for developers (and project managers) is the constant flow of business changes/requests • Some look simple, but have major implications Use Threat Models to control business
- 15. • Key challenge for developers (and project managers) is the constant flow of business changes/requests • Some look simple, but have major implications – usually because they don’t fit in the current architecture Use Threat Models to control business
- 16. • Key challenge for developers (and project managers) is the constant flow of business changes/requests • Some look simple, but have major implications – usually because they don’t fit in the current architecture • this is where Threat Models help since those ‘new features’ will require an revisit of existing Threat Models Use Threat Models to control business
- 17. • Key challenge for developers (and project managers) is the constant flow of business changes/requests • Some look simple, but have major implications – usually because they don’t fit in the current architecture • this is where Threat Models help since those ‘new features’ will require an revisit of existing Threat Models – Putting a gentle (positive) ’break’ in the current business requests Use Threat Models to control business
- 18. • Key challenge for developers (and project managers) is the constant flow of business changes/requests • Some look simple, but have major implications – usually because they don’t fit in the current architecture • this is where Threat Models help since those ‘new features’ will require an revisit of existing Threat Models – Putting a gentle (positive) ’break’ in the current business requests – Which means that the original brief is ‘locked’ Use Threat Models to control business
- 19. • Threat models should be set-up as sources of truth Sources of truth
- 20. • Threat models should be set-up as sources of truth • There should be a requirement to do a Threat Model for every app and feature Sources of truth
- 21. • Threat models should be set-up as sources of truth • There should be a requirement to do a Threat Model for every app and feature • Not doing Threat Models means that the security implications of the ‘new feature’ have not be considered and documented Sources of truth
- 22. • Threat models should be set-up as sources of truth • There should be a requirement to do a Threat Model for every app and feature • Not doing Threat Models means that the security implications of the ‘new feature’ have not be considered and documented • This is easier to put in place than a requirement to have ‘up-to-date documentation’ and ‘diagrams that represent the real world’ Sources of truth
- 23. • Creating and following a threat model for a feature is a great way to understand a threat model journey: Threat Model per Feature
- 24. • Creating and following a threat model for a feature is a great way to understand a threat model journey: – First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. Threat Model per Feature
- 25. • Creating and following a threat model for a feature is a great way to understand a threat model journey: – First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. – Next, you want to create a full flow of that feature. Look at the entry point and the assets, and look at what is being used in that feature. Threat Model per Feature
- 26. • Creating and following a threat model for a feature is a great way to understand a threat model journey: – First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. – Next, you want to create a full flow of that feature. Look at the entry point and the assets, and look at what is being used in that feature. – Now, you can map the inputs of the feature; you can map the data paths given by the data schema, and then you follow the data. Threat Model per Feature
- 27. • Creating and following a threat model for a feature is a great way to understand a threat model journey: – First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. – Next, you want to create a full flow of that feature. Look at the entry point and the assets, and look at what is being used in that feature. – Now, you can map the inputs of the feature; you can map the data paths given by the data schema, and then you follow the data. • You can see for example how the data go into the application, what it ends up with, who calls who. Threat Model per Feature
- 28. • Creating and following a threat model for a feature is a great way to understand a threat model journey: – First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. – Next, you want to create a full flow of that feature. Look at the entry point and the assets, and look at what is being used in that feature. – Now, you can map the inputs of the feature; you can map the data paths given by the data schema, and then you follow the data. • You can see for example how the data go into the application, what it ends up with, who calls who. • This means you have a much tighter brief, and a much better view of the situation. Threat Model per Feature
- 29. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) Chained threat models
- 30. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) – You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. Chained threat models
- 31. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) – You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. • For example, I have seen threat models where one will say, "Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests". Chained threat models
- 32. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) – You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. • For example, I have seen threat models where one will say, "Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests". • However, after doing a threat model of that system, we find that it does not have any DOS protections, even worse, it doesn't do any data validation/ sanitisation. Chained threat models
- 33. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) – You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. • For example, I have seen threat models where one will say, "Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests". • However, after doing a threat model of that system, we find that it does not have any DOS protections, even worse, it doesn't do any data validation/ sanitisation. • This means that the upstream service (which is 'trusted') is just glorified proxy,: Chained threat models
- 34. • When you create threat models per feature or per component, a key element is to start to chain them (i.e. map the connections between them) – You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. • For example, I have seen threat models where one will say, "Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests". • However, after doing a threat model of that system, we find that it does not have any DOS protections, even worse, it doesn't do any data validation/ sanitisation. • This means that the upstream service (which is 'trusted') is just glorified proxy,: – meaning that for all practices purposes, the 'internal' APIs and endpoints are directly connected to the upstream service callers (which is usually the internet, or other 'glorified proxies' services). Chained threat models
- 35. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. Pentest Confirms Threat Model
- 36. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. • Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. Pentest Confirms Threat Model
- 37. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. • Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. • There are three important steps to follow: Pentest Confirms Threat Model
- 38. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. • Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. • There are three important steps to follow: – Take the threat models per feature, per layer and confirm that there is no blind spots or variations on the expectation Pentest Confirms Threat Model
- 39. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. • Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. • There are three important steps to follow: – Take the threat models per feature, per layer and confirm that there is no blind spots or variations on the expectation – Check the code path to improve the understanding of the code path and what is happening in the threat model Pentest Confirms Threat Model
- 40. • A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. • Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. • There are three important steps to follow: – Take the threat models per feature, per layer and confirm that there is no blind spots or variations on the expectation – Check the code path to improve the understanding of the code path and what is happening in the threat model – Confirm that there are no extra behaviours Pentest Confirms Threat Model
- 41. • One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. Capture the success stories of your threat models
- 42. • One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. • One of my favourite moments occurs when the developers and the architects working on a threat model realise something that they hadn't noticed before. Capture the success stories of your threat models
- 43. • One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. • One of my favourite moments occurs when the developers and the architects working on a threat model realise something that they hadn't noticed before. – In such cases, sometimes it is the developer who says, "Oh, I never realised that is how it worked!". Capture the success stories of your threat models
- 44. • One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. • One of my favourite moments occurs when the developers and the architects working on a threat model realise something that they hadn't noticed before. – In such cases, sometimes it is the developer who says, "Oh, I never realised that is how it worked!". – Other times when the architect says, "Well, this is how app was designed", and the developer responds "Yeah, but that didn't work, so we did it like this." Capture the success stories of your threat models
- 45. RISK ACCEPTANCE
- 46. • All threats identified in Threat Models (not matter how small) need to be risk accepted Risk accepting all threats
- 47. • All threats identified in Threat Models (not matter how small) need to be risk accepted • Use the JIRA Risk Workflow Risk accepting all threats
- 48. • All threats identified in Threat Models (not matter how small) need to be risk accepted • Use the JIRA Risk Workflow Risk accepting all threats https://www.slideshare.net/DinisCruz/secdevops-risk-workflow-v06
- 49. More details on book (available for free) https://leanpub.com/secdevops