This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Threat Risk Modeling"

From OWASP
Jump to: navigation, search
(put a header to point to one main page)
 
(71 intermediate revisions by 22 users not shown)
Line 1: Line 1:
  
−
=Secure Coding Principles =[[Guide Table of Contents]]__TOC__
+
= THIS PAGE IS NOW A copy of the "Application Threat Modeling" page. Please edit [[Application Threat Modeling]] =
−
Architects and solution providers need guidance to produce secure applications by design, and they can do this by not only implementing the basic controls documented in the main text, but also referring back to the underlying “Why?” in these principles. Security principles such as confidentiality, integrity, and availability – although important, broad, and vague – do not change. Your application will be the more robust the more you apply them.
 
−
For example, it is a fine thing when implementing data validation to include a centralized validation routine for all form input. However, it is a far finer thing to see validation at each tier for all user input, coupled with appropriate error handling and robust access control.
 
−
In the last year or so, there has been a significant push to standardize terminology and taxonomy. This version of the Guide has normalized its principles with those from major industry texts, while dropping a principle or two present in the first edition of the Guide. This is to prevent confusion and to increase compliance with a core set of principles. The principles that have been removed are adequately covered by controls within the text.
 
−
==Asset Classification ==
 
−
Selection of controls is only possible after classifying the data to be protected. For example, controls applicable to low value systems such as blogs and forums are different to the level and number of controls suitable for accounting, high value banking and electronic trading systems.
 
−
==About attackers ==
 
−
When designing controls to prevent misuse of your application, you must consider the most likely attackers (in order of likelihood and actualized loss from most to least):
 
−
* Disgruntled staff or developers
 
−
* “Drive by” attacks, such as side effects or direct consequences of a virus, worm or Trojan attack
 
−
* Motivated criminal attackers, such as organized crime
 
−
* Criminal attackers without motive against your organization, such as defacers
 
−
* Script kiddies
 
−
Notice there is no entry for the term “hacker.” This is due to the emotive and incorrect use of the word “hacker” by the media. However, it is far too late to reclaim the incorrect use of the word “hacker” and try to return the word to its correct roots. The Guide consistently uses the word “attacker” when denoting something or someone who is actively attempting to exploit a particular feature.
 
−
==Core pillars of information security ==
 
−
Information security has relied upon the following pillars:
 
−
* Confidentiality – only allow access to data for which the user is permitted
 
−
* Integrity – ensure data is not tampered or altered by unauthorized users
 
−
* Availability – ensure systems and data are available to authorized users when they need it
 
−
The following principles are all related to these three pillars. Indeed, when considering how to construct a control, considering each pillar in turn will assist in producing a robust security control.
 
−
==Security Architecture ==
 
−
Applications without security architecture are as bridges constructed without finite element analysis and wind tunnel testing. Sure, they look like bridges, but they will fall down at the first flutter of a butterfly’s wings. The need for application security in the form of security architecture is every bit as great as in building or bridge construction.
 
−
Application architects are responsible for constructing their design to adequately cover risks from both typical usage, and from extreme attack. Bridge designers need to cope with a certain amount of cars and foot traffic but also cyclonic winds, earthquake, fire, traffic incidents, and flooding. Application designers must cope with extreme events, such as brute force or injection attacks, and fraud. The risks for application designers are well known. The days of “we didn’t know” are long gone. Security is now expected, not an expensive add-on or simply left out.
 
−
Security architecture refers to the fundamental pillars: the application must provide controls to protect the confidentiality of information, integrity of data, and provide access to the data when it is required (availability) – and only to the right users. Security architecture is not “markitecture”, where a cornucopia of security products are tossed together and called a “solution”, but a carefully considered set of features, controls, safer processes, and default security posture.
 
−
When starting a new application or re-factoring an existing application, you should consider each functional feature, and consider:
 
−
* Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
 
−
* If I were evil, how would I abuse this feature?
 
−
* Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?
 
−
Andrew van der Stock calls the above process “Thinking Evil™”, and recommends putting yourself in the shoes of the attacker and thinking through all the possible ways you can abuse each and every feature, by considering the three core pillars and using the STRIDE model in turn.
 
−
By following this guide, and using the STRIDE / DREAD threat risk modeling discussed here and in Howard and LeBlanc’s book, you will be well on your way to formally adopting a security architecture for your applications.
 
−
The best system architecture designs and detailed design documents contain security discussion in each and every feature, how the risks are going to be mitigated, and what was actually done during coding.
 
−
Security architecture starts on the day the business requirements are modeled, and never finish until the last copy of your application is decommissioned. Security is a life-long process, not a one shot accident.
 
−
==Security Principles ==
 
−
These security principles have been taken from the previous edition of the OWASP Guide and normalized with the security principles outlined in Howard and LeBlanc’s excellent ''Writing Secure Code''.
 
−
===Minimize Attack Surface Area ===
 
−
Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area.
 
−
For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.
 
−
===Secure Defaults ===
 
−
There are many ways to deliver an “out of the box” experience for users. However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed.
 
−
For example, by default, password aging and complexity should be enabled. Users might be allowed to turn these two features off to simplify their use of the application and increase their risk.
 
−
===Principle of Least Privilege ===
 
−
The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.
 
−
For example, if a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.
 
−
===Principle of Defense in Depth ===
 
−
The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.
 
−
With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.
 
−
For example, a flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.
 
−
===Fail securely ===
 
−
Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not.
 
−
For example:
 
−
isAdmin = true;
 
−
try {
 
−
codeWhichMayFail();
 
−
isAdmin = isUserInRole( “Administrator” );
 
−
}
 
−
catch (Exception ex) {
 
−
log.write(ex.toString());
 
−
}
 
−
If codeWhichMayFail() fails, the user is an admin by default. This is obviously a security risk.
 
−
===External Systems are Insecure ===
 
−
Many organizations utilize the processing capabilities of third party partners, who more than likely have differing security policies and posture than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners.
 
−
Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.
 
−
For example, a loyalty program provider provides data that is used by Internet Banking, providing the number of reward points and a small list of potential redemption items. However, the data should be checked to ensure that it is safe to display to end users, and that the reward points are a positive number, and not improbably large.
 
−
===Separation of Duties ===
 
−
A key fraud control is separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived.
 
−
Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.
 
−
For example, an administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.
 
−
===Do not trust Security through Obscurity  ===
 
−
Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.
 
−
For example, the security of an application should not rely upon knowledge of the source code being kept secret. The security should rely upon many other factors, including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls.
 
−
A practical example is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.
 
−
===Simplicity ===
 
−
Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code.
 
−
Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.
 
−
For example, although it might be fashionable to have a slew of singleton entity beans running on a separate middleware server, it is more secure and faster to simply use global variables with an appropriate mutex mechanism to protect against race conditions.
 
−
===Fix Security Issues Correctly ===
 
−
Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.
 
−
For example, a user has found that they can see another user’s balance by adjusting their cookie. The fix seems to be relatively straightforward, but as the cookie handling code is shared amongst all applications, a change to just one application will trickle through to all other applications. The fix must therefore be tested on all affected applications.
 
−
 
  
 +
Threat modelling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.
  
 +
Threat modelling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the internet of things, business processes, etc. There are very few technical products which cannot be threat modelled; more or less rewarding, depending on how much it communicates, or interacts, with the world. Threat modelling can be done at any stage of development, preferably early - so that the findings can inform the design.
 +
==What==
 +
Most of the time, a threat model includes:
 +
*A description / design / model of what you’re worried about
 +
*A list of assumptions that can be checked or challenged in the future as the threat landscape changes
 +
*A list of potential threats to the system
 +
*A list of actions to be taken for each threat
 +
*A way of validating the model and threats, and verification of success of actions taken
 +
Our motto is: Threat modelling: the sooner the better, but never too late.
 +
==Why==
 +
The inclusion of threat modelling in the SDLC can help
 +
*Build a secure design
 +
*Efficient investment of resources; appropriately prioritize security, development, and other tasks
 +
*Bring Security and Development together to collaborate on a shared understanding, informing development of the system
 +
*Identify threats and compliance requirements, and evaluate their risk
 +
*Define and build required controls.
 +
*Balance risks, controls, and usability
 +
*Identify where building a control is unnecessary, based on acceptable risk
 +
*Document threats and mitigation
 +
*Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
 +
*Identification of security test cases / security test scenarios to test the security requirements
 +
==4 Questions==
 +
Most threat model methodologies answer one or more of the following questions:
 +
===1. What are we building?===
 +
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:
 +
*Architecture diagrams
 +
*Dataflow transitions
 +
*Data classifications
 +
*You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise.
 +
===2. What can go wrong?===
 +
This is a research activity in which you want to find the main threats that apply to your application.
 +
===3. What are we going to do about that?===
 +
In this phase you turn your findings into specific actions.
 +
===4. Did we do a good enough job?===
 +
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning.
 +
==Process==
 +
The technical steps in threat modelling involve answering questions: - What are we working on - What can go wrong - What will we do with the findings - Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls.
  
 +
The effort, work, and timeframes spent on threat modelling relate to the process in which engineering is happening and products/services are delivered. The idea that threat modelling is waterfall or ‘heavyweight’ is based on threat modelling approaches from the early 2000s. Modern threat modelling building blocks fit well into agile and are in wide use.
 +
====When to threat model====
 +
When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious.
  
−
[[Guide Table of Contents]]
+
Threat modelling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task.
 +
 
 +
After a security incident, going back and checking the threat models can be an important process.
 +
====Threat modelling: engagement versus review====
 +
Threat modelling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modelling, yet quite different.
 +
====Validating assumptions====
 +
==Learning More==
 +
====Agile approaches====
 +
*Main agile threat modelling page
 +
*Specific agile approach1 TM page
 +
*Specific agile approach2 TM page
 +
====Waterfall approaches====
 +
*Main waterfall TM page
 +
==Additional/External references==
 +
__TOC__
 +
[[Category:FIXME|Change%25203rd%2520orange%2520box%2520in%2520graphic%2520to%2520"Authorization%2520MAY%2520fail"]]
 +
[[Category:FIXME|link not working, please replace]]
 +
[[Category:FIXME|link not working, please replace]]
 
[[Category:OWASP_Guide_Project]]
 
[[Category:OWASP_Guide_Project]]
 +
[[Category:Activity]]
 +
[[Category:Externally Linked Page]]
 +
[[Category:Threat_Modeling]]
 +
[[Category:SAMM-TA-1]]
 +
[[Category:FIXME|The first two are more scenarios than advantages]]

Latest revision as of 15:09, 11 June 2018

THIS PAGE IS NOW A copy of the "Application Threat Modeling" page. Please edit Application Threat Modeling

Threat modelling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

Threat modelling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the internet of things, business processes, etc. There are very few technical products which cannot be threat modelled; more or less rewarding, depending on how much it communicates, or interacts, with the world. Threat modelling can be done at any stage of development, preferably early - so that the findings can inform the design.

What

Most of the time, a threat model includes:

  • A description / design / model of what you’re worried about
  • A list of assumptions that can be checked or challenged in the future as the threat landscape changes
  • A list of potential threats to the system
  • A list of actions to be taken for each threat
  • A way of validating the model and threats, and verification of success of actions taken

Our motto is: Threat modelling: the sooner the better, but never too late.

Why

The inclusion of threat modelling in the SDLC can help

  • Build a secure design
  • Efficient investment of resources; appropriately prioritize security, development, and other tasks
  • Bring Security and Development together to collaborate on a shared understanding, informing development of the system
  • Identify threats and compliance requirements, and evaluate their risk
  • Define and build required controls.
  • Balance risks, controls, and usability
  • Identify where building a control is unnecessary, based on acceptable risk
  • Document threats and mitigation
  • Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
  • Identification of security test cases / security test scenarios to test the security requirements

4 Questions

Most threat model methodologies answer one or more of the following questions:

1. What are we building?

As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:

  • Architecture diagrams
  • Dataflow transitions
  • Data classifications
  • You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise.

2. What can go wrong?

This is a research activity in which you want to find the main threats that apply to your application.

3. What are we going to do about that?

In this phase you turn your findings into specific actions.

4. Did we do a good enough job?

Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning.

Process

The technical steps in threat modelling involve answering questions: - What are we working on - What can go wrong - What will we do with the findings - Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls.

The effort, work, and timeframes spent on threat modelling relate to the process in which engineering is happening and products/services are delivered. The idea that threat modelling is waterfall or ‘heavyweight’ is based on threat modelling approaches from the early 2000s. Modern threat modelling building blocks fit well into agile and are in wide use.

When to threat model

When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious.

Threat modelling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task.

After a security incident, going back and checking the threat models can be an important process.

Threat modelling: engagement versus review

Threat modelling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modelling, yet quite different.

Validating assumptions

Learning More

Agile approaches

  • Main agile threat modelling page
  • Specific agile approach1 TM page
  • Specific agile approach2 TM page

Waterfall approaches

  • Main waterfall TM page

Additional/External references

Retrieved from "https://wiki.owasp.org/index.php?title=Threat_Risk_Modeling&oldid=241244"