Threat model can be done at different levels of abstraction and in different phases of the SDLC.
If the more consolidated techniques are about creating a Threat model in the design phase (before implementation). Nowadays needs are often to integrate TM inside a maintained (production) system that may also have an Agile methodology of development; new features coming in all the time.
When we want to approach a design level TM we most likely will use architectural, design, and data flow diagrams (DFD). Security architects and engineers will apply a more rigorous framework (e.g. STRIDE) create a TM document and maintain it. The TM is on a whole application scope.
When delivering a single feature (Story or Epic in Agile terminology) we should also apply TM techniques that imply adversarial mindset, delivers mitigations, improve implementation and show documentable security efforts. In this case is advisable to follow a different modus operandi, much lighter, and agile developer oriented. Abuse cases, in this case, are the outcomes of finding out the most important TM question: "What can go wrong?".
There is also an even wider than application level scope for doing TM, based on a whole organization risk or in an application ecosystem (including downstream data systems involved). Those are methodologies like PASTA Risk (or data) centric threat modeling and would require, rightly, a much bigger effort.
In the following schema an (over) simplification of Threat modeling scope and the relative TM framework/techniques.
Of course, in PASTA you have application decomposition that involves lower/reduced scopes. Aggregating lower scope TMs helps represent higher scopes TM as well.
Following some examples of different scope levels:
Feature: adding third-party Javascript in website to implement chat.
Abuse Case 1: An attacker could use the service to send a malicious link to the operator that can lead to information disclosure and elevation of privileges. The mitigation could be 1) to restrict the type of content that the chat can handle. 2) Specific training for chat operators.
Abuse Case 2: The third party Javascript supplier begins unreliable and sends a malicious Javascript instead (this is equivalent to a stores XSS). A mitigation is not to use direct links to the JS provider, instead, use our own CDN that also reduces attack surface/num of attack vectors [...]
Of course abuse cases may have a rigid structure e.g.: As an [ATTACKER_TYPE] I could [IMPACT CREATED] so we put in place [MITIGATION]
It is then possible to complete Application level TM by collecting this structure data in an incremental, maintained and developer centric way.
References & examples from:
If the more consolidated techniques are about creating a Threat model in the design phase (before implementation). Nowadays needs are often to integrate TM inside a maintained (production) system that may also have an Agile methodology of development; new features coming in all the time.
When we want to approach a design level TM we most likely will use architectural, design, and data flow diagrams (DFD). Security architects and engineers will apply a more rigorous framework (e.g. STRIDE) create a TM document and maintain it. The TM is on a whole application scope.
When delivering a single feature (Story or Epic in Agile terminology) we should also apply TM techniques that imply adversarial mindset, delivers mitigations, improve implementation and show documentable security efforts. In this case is advisable to follow a different modus operandi, much lighter, and agile developer oriented. Abuse cases, in this case, are the outcomes of finding out the most important TM question: "What can go wrong?".
There is also an even wider than application level scope for doing TM, based on a whole organization risk or in an application ecosystem (including downstream data systems involved). Those are methodologies like PASTA Risk (or data) centric threat modeling and would require, rightly, a much bigger effort.
In the following schema an (over) simplification of Threat modeling scope and the relative TM framework/techniques.
Following some examples of different scope levels:
Abuse case example (could be a Jira Story issue):
Feature: adding third-party Javascript in website to implement chat.
Abuse Case 1: An attacker could use the service to send a malicious link to the operator that can lead to information disclosure and elevation of privileges. The mitigation could be 1) to restrict the type of content that the chat can handle. 2) Specific training for chat operators.
Abuse Case 2: The third party Javascript supplier begins unreliable and sends a malicious Javascript instead (this is equivalent to a stores XSS). A mitigation is not to use direct links to the JS provider, instead, use our own CDN that also reduces attack surface/num of attack vectors [...]
Of course abuse cases may have a rigid structure e.g.: As an [ATTACKER_TYPE] I could [IMPACT CREATED] so we put in place [MITIGATION]
It is then possible to complete Application level TM by collecting this structure data in an incremental, maintained and developer centric way.
References & examples from:
- https://2017.appsec.eu/presos/CISO/Threat%20Modeling%20with%20PASTA%20-%20Risk%20Centric%20Application%20Threat%20Modeling%20Case%20Studies%20-%20Tony%20UcedaV%C3%A9lez%20-%20OWASP_AppSec-Eu_2017.pdf
- https://drive.google.com/file/d/1f-Z7_FvOJKfTgWmzERvK0N1YFnKDck1v/view
Some insights come from: https://open-security-summit.org/outcomes/threat-modeling/working-sessions/future-of-threat-modelling/
ReplyDeleteCaesars on line casino is a legendary model that has repeatedly appeared in Hollywood motion pictures. As such, it is no surprise players can find massive collection of slots and table games. On top of that, you're routinely a part of|part of} the Caesars Rewards program. Our 25-step review course of is carefully designed to ensure each on line casino we suggest is of the very thecasinosource.com best quality.
ReplyDelete