Shortened Threat modeling section

.wordlist-en.txt

@@ -20,6 +20,7 @@ BOM
 BOMs
 BOV
 BetterEm
+Bridewell
 Brømsø
 CAPEC
 CCM

draft/06-design/01-threat-modeling/01-threat-modeling.md

@@ -24,211 +24,139 @@ and the philosophy of this section tries to follow the [Threat Modeling Manifest
 
 #### Overview
 
-Threat modeling activities try to discover what can go wrong with a system and determine what to do about it.
-The deliverables from threat modeling take various forms including system models and diagrams, lists of threats,
-mitigations or assumptions, meeting notes, and more.
-This may be assembled into a single threat model document; a structured representation of all the information
-that affects the security of an application.
-A good overview of this activity is given in the [Security Culture][culturetm] project section on threat modeling.
-
-In essence, it is a view of the application and its environment through security glasses.
-
-Threat modeling is a process for capturing, organizing, and analyzing all of this information
-and enables informed decision-making about application security risk.
-In addition to producing a model, typical threat modeling efforts also produce a prioritized list
-of _potential_ security vulnerabilities in the concept, requirements, design, or implementation.
-Any potential vulnerabilities that have been identified from the model should then be remediated
-using one of the common strategies: mitigate, eliminate, transfer or accept the threat of being exploited.
+Zero-day attacks can be extremely harmful, and we don't want developers to be in the blind side of things when it
+comes to security of the ideas they implement. This is why teams are encouraged to use threat modeling practices.
 
-There are many reasons for doing threat modeling but the most important one is that this activity is _useful_ ,
-it is probably the only stage in a development lifecycle where a team sits back and asks: 'What can go wrong?'.
+These practices try to discover what can go wrong with a system and help determine what to do about it.
+It helps teams make system models and diagrams, give thought to potential threats and mitigations and more.
+A good overview of this activity is given in the [Security Culture][culturetm] project section on threat modeling.
 
-There are other reasons for threat modeling, for example standards compliance or analysis for disaster recovery,
-but the main aim of threat modeling is to remedy (possible) vulnerabilities before the malicious actors can exploit them.
+The documentation below is a small introduction to the idea aimed at developers who are trying this out for the
+first time. For a more detailed approach to threat modeling, you can read the [Threat modeling cheat sheet][cstm]
+by owasp.
 
 #### What is threat modeling
 
-Threat modeling works to identify, communicate, and understand threats and mitigations
-within the context of protecting something of value.
+Threat modeling stands as a procedural guideline to ensuring security of a teams output.
 
-Threat modeling 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 modeled;
-more or less rewarding, depending on how much it communicates, or interacts, with the world.
+It can be applied to software, applications, systems, networks, distributed systems,
+Internet of things implementations, business processes, and more.
 
-A threat model document is a record of the threat modeling process, and often includes:
+The goal is to create a record that 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
 * potential threats to the system
 * remediation / actions to be taken for each threat
 * ways of validating the model and threats, and verification of success of actions taken
 
-The threat model should be in a form that can be easily revised and modified
-during subsequent threat modeling discussions.
-
 #### Why do it
 
-Like all engineering activities, effort spent on threat modeling has to be justifiable.
-Rarely any project or development has engineering effort that is going 'spare',
-and the benefits of threat modeling have to outweigh the engineering cost of this activity.
-Usually this is difficult to quantify; an easier way to approach it may be to ask
-what are the costs of _not_ doing threat modeling?
-These costs may consist of a lack of compliance, an increased risk of being exploited, harm to reputation and so on.
+The efforts spent on threat modeling is justified when we consider the alternative,
+that is _no threat modeling_. Products where this due diligence has not been implemented,
+are at a blind risk of attacks.
 
 The inclusion of threat modeling in the secure development activities 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
+* Bring Security and Development together
 * 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
 
-Threat modeling also provides a clear 'line of sight' across a project that can be used
-to justify other security efforts.
-The threat model allows security decisions to be made rationally, with all the information available,
-so that security decisions can be properly supported.
-The threat modeling process naturally produces an assurance argument that can be used to explain
-and defend the security of an application.
-An assurance argument starts with a few high level claims and then justifies them with either sub-claims or evidence.
+[This blog][tmimp] by Bridewell on the subject justifies this to an
+enterprise level (if risk mitigation wasn't enough!)
 
 #### When to threat model
 
-There is no wrong time to do threat modeling;
-the earlier it is done in the development lifecycle the more beneficial it is,
-but it threat modeling is also useful at any time during application development.
-
-Threat modeling is best applied continuously throughout a software development project.
-The process is essentially the same at different levels of abstraction,
-although the information gets more and more granular throughout the development lifecycle.
-Ideally, a high-level threat model should be defined in the concept or planning phase,
-and then refined during the development phases.
-As more details are added to the system new attack vectors are identified,
-so the ongoing threat modeling process should examine, diagnose, and address these threats.
+It is beneficial to perform this analysis at anytime during development. It is best applied continuously
+throughout a software development project.
+This is a dynamic procedure and with more features added to the product, there are more risks involved.
 
-Note that it is a natural part of refining a system for new threats to be exposed.
-When you select a particular technology, such as Java for example,
-you take on the responsibility to identify the new threats that are created by that choice.
-Even implementation choices such as using regular expressions for validation
-introduce potential new threats to deal with.
-
-Threat modeling: _the sooner the better, but never too late_
+For example, small things like introducing regex for user input introduces bypass strings!
 
 #### Questions to ask
 
-Often threat modeling is a conceptual activity rather than a rigorous process,
-where development teams are brought together and asked to think up ways of subverting their system.
-To provide some structure it is useful to start with Shostack's [Four Question Framework][4QFW]:
-
-**1 What are we working on**?
+Threat modeling is more conceptual, with development teams coming together and thinking of
+ways of subverting their system.
 
-As a starting point the scope of the Threat Model should be defined.
-This will require an understanding of the application that is being built,
-and some examples of inputs for the threat model could be:
+To provide some structure it is useful to start with Shostack's [Four Question Framework][4QFW]
+as described briefly below:
 
-* Architecture diagrams
-* Dataflow transitions
-* Data classifications
+**1 What are we working on?'**?
 
-It is common to represent the answers to this question with one or more data flow diagrams
-and often supplemental diagrams like message sequence diagrams.
+The first step is to understand the application through architecture diagrams,
+data flows, and classifications. This step is enhanced when people from different roles
+can pitch in and give inputs.
 
-It is best to gather people from different roles with sufficient technical and risk awareness
-so that they can agree on the framework to be used during the threat modeling exercise.
+The base must be understood perfectly before attempting to figure out vulnerabilities.
 
 **2 What can go wrong**?
 
-This is a research activity to find the main threats that apply to your application.
-There are many ways to approach the question, including open discussion or using a structure to help think it through.
-Techniques and methodologies to consider include CIA, [STRIDE][stride], [LINDDUN][linddun],
-[cyber kill chains][chains], [PASTA][pasta], common attack patterns ([CAPEC][capec]) and others.
+Then you must research potential risks. This can be done using frameworks like
+[STRIDE][stride], [LINDDUN][linddun], and [CAPEC][capec].
 
-There are resources available that will help with identifying threats and vulnerabilities.
-OWASP provide a set of cards, [Cornucopia][corncards], that provide suggestions and explanations for general vulnerabilities.
-The game [Elevation of Privileges][eop] threat modeling card game is an easy way to get started with threat modeling,
-and there is the OWASP version of [Snakes and Ladders][snakes] that truly gamifies these activities.
+OWASP provides a set of cards, [Cornucopia][corncards] to provide suggestions for general
+vulnerabilities.
+To make the process more fun, [Elevation of Privileges][eop] can be used or its OWASP version
+[Snakes and Ladders][snakes].
 
 **3 What are we going to do about that**?
 
-In this phase turn the threat model findings into specific actions.
-Consider the appropriate remediation for each threat identified: Transfer, Avoid, Mitigate or Eliminate.
+Now these threats need to be addressed by either:
 
-**4 Did we do a good enough job**?
+* transfer
+* avoidance
+* mitigation
+* elimination
 
-Finally, carry out a retrospective activity over the work identified to check
-quality, feasibility, progress, or planning.
+**4 Did we do a good enough job**?
 
-The OWASP [Threat Modeling Playbook][tmpb] goes into these practicalities in more detail
-and provides strategies for maintaining threat modeling within an organization.
+Lastly, teams must review the process for quality, feasibility, and progress.
+A good reference is the OWASP [Threat Modeling Playbook][tmpb] for long-term strategies.
 
 #### How to do it
 
-There is no one process for threat modeling.
-How it is done in practice will vary according to the organization's culture,
-according to what type of system / application is being modeled
-and according to preferences of the development team itself.
-The various techniques and concepts are discussed in the [Threat Modeling Cheat Sheet][cstm]
-and can be summarized:
-
-1. Terminology: try to use standard terms such as actors, trust boundaries, etc as this will help convey these concepts
-2. Scope: be clear what is being modeled and keep within this scope
-3. Document: decide which tools and what outputs are required to satisfy compliance, for example
-4. Decompose: break the system being modeled into manageable pieces
-5. Trust: identify your trust boundaries, consider [network segmentation][ccsnet]
-6. Agents: identify who the actors are (malicious or otherwise) and what they can do
-7. Categorize: prioritize the threats taking into account probability, impact and any other factors
-8. Remediation: be sure to decide what to do about any threats identified, the whole reason for threat modeling
-
-It is worth saying this again: there are many ways to do threat modeling,
-all perfectly valid, so choose the right process that works for a specific team.
+Threat modeling is not standardized and depends on how the organization exactly
+wants to carry it out. However, a good set of procedures are defined in the
+[Threat Modeling Cheat Sheet][cstm] which are summarized below:
+
+* Define clear scopes and stick to them
+* Fix on tools and outputs required early on
+* Use standard terminology throughout the document
+* Categorize the threat with respect to probability of occurrence
+    and impact.
+* Have a remediation planned for each threat.
 
 #### Final advice
 
 Some final words on threat modeling.
 
 **Make it incremental**:
 
-Strongly consider using [incremental threat modeling][sammgata].
-It is almost certainly a bad idea trying to fully model an existing application or system;
-it can be very time consuming modeling a whole system,
-and by the time such a model was completed then it would probably be out of date.
-Instead incrementally model new features or enhancements as and when they are being developed.
+It is important to focus on new features and not entire systems. Consider using
+[incremental threat modeling][sammgata] which allows for new features to be tested
+as and when they're implemented.
 
-Incremental threat modeling assumes that existing applications and features
-have already been attacked over time and these real world vulnerabilities have been remediated.
-It is the new features or new applications that pose a greater security risk;
-if they are vulnerable then they will reduce the security of the existing application or system.
-Concentrating on the new changes applies threat modeling effort at the place that it is needed most;
-at the very least the changes should not make the security worse - and ideally the security should be better.
+This is recommended because modeling a full system can lead to missed threats while
+also taking much more time.
 
 **Tools are secondary**:
 
-It is good to standardize threat modeling tools across an organization,
-but also allow teams to choose how they record their threat models.
-If one team decides to use Threat Dragon, for example, and another wants to use a drawing board,
-then that is usually fine.
-The discussions had during the threat modeling process are more important than the tool used,
-although you might ask the team using the drawing board how they implement change control for their models.
+The discussion between teams and different development groups matters
+more than tools. You must ensure flexibility in your organization with regards
+to the tools used by different teams.
 
 **Brevity is paramount**:
 
-It is very easy to create a threat model that looks a lot like a system diagram, with many components and data flows.
-This makes for a convincing diagram, but it is not a model specific to the threat of exploits.
-Instead concentrate on the attack / threat surfaces and be robust in consolidating multiple system components
-into one threat model component.
-This will keep the number of components and dataflows manageable, and focuses the discussion on what matters most:
-malicious actors (external or internal) trying to subvert your system.
+Make sure that your threat model is not so complex that people aren't able to
+understand it! Because in such a case, its useless.
+
+It is a good idea to keep models focused on threat surfaces, not complex system diagrams.
 
 **Choose your methodology**:
 
 It is a good strategy to choose a threat categorization methodology for the whole organization
-and then try and keep to it.
+and keep to it.
 For example this could be [STRIDE][stride] or [LINDDUN][linddun], but if the CIA triad provides enough granularity
 then that is also a perfectly good choice.
 
@@ -256,6 +184,7 @@ then that is also a perfectly good choice.
 * [threatspec](https://github.com/threatspec/threatspec), an open source tool based on comments inline with code
 * MITRE's Common Attack Pattern Enumeration and Classification ([CAPEC][capec])
 * NIST [Common Vulnerability Scoring System Calculator][nist-cvss]
+* OWASP [Network Segmentation Cheat Sheet][ccsnet]
 
 ----
 
@@ -284,6 +213,7 @@ then [submit an issue][issue060101] or [edit on GitHub][edit060101].
 [snakes]: https://owasp.org/www-project-snakes-and-ladders/
 [stride]: https://en.wikipedia.org/wiki/STRIDE_%28security%29
 [tdtm]: https://owasp.org/www-project-threat-dragon/
+[tmimp]: https://www.bridewell.com/insights/blogs/detail/what-is-threat-modelling-and-why-is-it-important
 [tmpb]: https://owasp.org/www-project-threat-modeling-playbook/
 [tmproject]: https://owasp.org/www-project-threat-model/
 [tmmanifesto]: https://www.threatmodelingmanifesto.org/