update sections after proof reading

Author: jgadsden

.wordlist.txt

@@ -37,7 +37,6 @@ Wordlist
 XSS
 YAML
 aSemy
-albertvolkman
 backrefs
 bracex
 codefences
@@ -474,4 +473,5 @@ linddun
 LINNDUN
 DPO
 CISO
-iteratively
+iteratively
+ai

draft/05-requirements/01-requirements.md

@@ -22,10 +22,10 @@ with regulatory and statutory requirements being an important subset of both the
 #### Overview
 
 Security requirements are part of every secure development process
-and form the foundation for the application's security posture - they will certainly help with
-the prevention of many types of vulnerabilities.
+and form the foundation for the application's security posture.
+Requirements will certainly help with the prevention of many types of vulnerabilities.
 
-Requirements can come from many sources and in general there are three main sources:
+Requirements come from various sources, three common ones being:
 
 1. Software-related requirements which specify objectives and expectations
     to protect the service and data at the core of the application
@@ -99,7 +99,7 @@ the only general advice is to be familiar with and follow the appropriate statut
 The security requirements should be identified and recorded at the beginning of any new development
 and also when new features are added to an existing application.
 These security requirements should be periodically revisited and revised as necessary;
-for example security standards are updated and new standards come into force,
+for example security standards are updated and new regulations come into force,
 both of which may have a direct impact on the application.
 
 #### Further reading

draft/05-requirements/02-risk.md

@@ -79,7 +79,7 @@ Examples:
 2. Acceptance: sometimes a risk is low enough in priority, or the outcome bearable, that it is not worth mitigating,
     an example might be where the version of software is revealed but this is acceptable (or even desirable)
 
-3. Mitigation: it is usual to mitigate the impact of a risk, for example
+3. Mitigation: it is common to implement a security control to mitigate the impact of a risk, for example
     input sanitization or output encoding may be used for information supplied by an untrusted source,
     or the use of encrypted communication channels for transferring high risk information
 

draft/05-requirements/04-security-rat.md

@@ -15,7 +15,7 @@ permalink: /draft/requirements/security_rat/
 ### 3.4 SecurityRAT
 
 The [OWASP SecurityRAT][srat] (Requirement Automation Tool) is used to generate and manage security requirements
-that are obtained the [OWASP ASVS][asvs] project.
+using information from the [OWASP ASVS][asvs] project.
 It also provides an automated approach to requirements management
 during development of frontend, server and mobile applications.
 
@@ -28,7 +28,7 @@ it can be used to generate an initial set of requirements from the ASVS
 and then keep track of the status and updates for these requirements.
 It comes with [documentation and instructions][sratdocs] on how to install and run SecurityRAT.
 
-To generate the initial list of requirements SecurityRAT needs to be provided with three attributes defined by the ASVS:
+To generate the initial list of requirements, SecurityRAT needs to be provided with three attributes defined by the ASVS:
 
 * Application Security Verification Standard chapter ID - for example 'V2 - Authentication'
 * Application Security Verification Level - the compliance level, for example 'L2'

draft/05-requirements/05-asvs.md

@@ -23,7 +23,7 @@ the [github markdown][asvsmd] pages directly - this will ensure that the latest
 
 #### What is ASVS?
 
-The ASVS is an open standard that sets out the coverage and 'level of rigor' expected when it comes to
+The ASVS is an open standard that sets out the coverage and level of rigor expected when it comes to
 performing web application security verification.
 The standard also provides a basis for testing any technical security controls
 that are relied on to protect against vulnerabilities in the application.

draft/05-requirements/toc.md

@@ -14,9 +14,6 @@ permalink: /draft/requirements/
 
 ## 3. Requirements
 
-Understanding of key security requirements is outlined in the [Security Requirements][sammdsr] business function
-within the OWASP [SAMM model][samm].
-
 Referring to the OWASP [Top Ten Proactive Controls][control1], security requirements are statements of
 security functionality that ensure the different security properties of a software application are being satisfied.
 Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities.
@@ -28,7 +25,14 @@ Instead of creating a custom approach to security for every application,
 standard security requirements allow developers to reuse the definition of security controls and best practices;
 those same vetted security requirements provide solutions for security issues that have occurred in the past.
 
-So you can look at it this way: requirements exist to prevent the repeat of past security failures.
+The importance of understanding key security requirements is described in the [Security Requirements][sammdsr]
+practice that is part of the [Design][sammd] business function section within the OWASP [SAMM model][samm].
+Ideally structured software security requirements are available within with a security a requirements framework,
+and these are utilized by both developer teams and product teams.
+In addition suppliers to the organization must meet security requirements;
+build security into supplier agreements in order to ensure compliance with organizational security requirements.
+
+In summary, security requirements exist to prevent the repeat of past security failures.
 
 Sections:
 
@@ -48,4 +52,5 @@ then [submit an issue][issue0500] or [edit on GitHub][edit0500].
 [edit0500]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/toc.md
 [issue0500]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/00-toc
 [samm]: https://owaspsamm.org/about/
+[sammd]: https://owaspsamm.org/model/design/
 [sammdsr]: https://owaspsamm.org/model/design/security-requirements/

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

@@ -14,13 +14,13 @@ order:
 ### 4.1 Threat modeling
 
 Referring to the [Threat Modeling Cheat Sheet][tmcs],
-threat modeling is a structured approach of identifying and prioritizing potential threats to a system.
+threat modeling is a structured approach to identifying and prioritizing potential threats to a system.
 The threat modeling process includes determining the value that potential mitigations would have
 in reducing or neutralizing these threats.
 
 Assessing potential threats during the design phase of your project can save significant resources
-that might be needed to refactor the project to include risk mitigations during a later phase of the project.
-The outputs from the threat modeling activities generally include:
+if during a later phase of the project refactoring is required to include risk mitigations.
+The outcomes from the threat modeling activities generally include:
 
 * Documenting how data flows through a system to identify where the system might be attacked
 * Identifying as many potential threats to the system as possible

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

@@ -27,16 +27,16 @@ This may be assembled into a single threat model document; a structured represen
 that affects the security of an application.
 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.
+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.
 
 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?'
+it is probably the only stage in a development lifecycle where a team sits back and asks: 'What can go wrong?'.
+
 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.
 
@@ -84,7 +84,7 @@ The inclusion of threat modeling in the secure development activities can help:
     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
+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.
@@ -107,7 +107,7 @@ 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.
 
 Note that it is a natural part of refining a system for new threats to be exposed.
-For example, when you select a particular technology, such as Java for example,
+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.
@@ -183,7 +183,7 @@ all perfectly valid, so choose the right process that works for a specific team.
 
 #### Final advice
 
-Finally some advice on threat modeling.
+Some final words on threat modeling.
 
 **Make it incremental**:
 
@@ -207,7 +207,7 @@ 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 their change control.
+although you might ask the team using the drawing board how they implement change control for their models.
 
 **Brevity is paramount**:
 
@@ -222,8 +222,8 @@ malicious actors (external or internal) trying to subvert your system.
 
 It is a good strategy to choose a threat categorisation methodology for the whole organisation
 and then try and keep to it.
-This could be [STRIDE][stride] or [LINDDUN][linddun], but if the [CIA][cia] triad gives enough granularity
-then that is a perfectly good choice.
+For example this could be [STRIDE][stride] or [LINDDUN][linddun], but if the [CIA][cia] triad provides enough granularity
+then that is also a perfectly good choice.
 
 #### Further reading
 

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

@@ -1,6 +1,6 @@
 ---
 
-title: Threat Modeling with pytm
+title: Pythonic Threat Modeling
 layout: col-document
 tags: OWASP Developer Guide
 contributors: Jon Gadsden
@@ -17,7 +17,7 @@ permalink: /draft/design/threat_modeling/pytm/
 The OWASP [Pythonic Threat Modeling (pytm)][pytmproject] project is a framework for threat modeling and its automation.
 The goal of pytm is to shift threat modeling to the left, making threat modeling more automated and developer-centric.
 
-Pytm is an OWASP Lab Project with a community of contributors creating [several releases][pytmreleases].
+Pytm is an OWASP Lab Project with a community of contributors creating [regular releases][pytmreleases].
 
 #### What is pytm?
 
@@ -39,10 +39,11 @@ The OWASP Spotlight series provides an overview of pytm: 'Project 6 - [OWASP pyt
 
 #### Why use pytm?
 
-The pytm development team state that traditional threat modeling often comes too late in the development process,
-and sometimes may not happen at all.
+The pytm development team make the good point that traditional threat modeling often comes too late
+in the development process, and sometimes may not happen at all.
 In addition, creating manual / diagrammatic data flows and reports can be extremely time-consuming.
-These are very good points, and pytm attempts to get threat modeling to 'shift-left' in the development lifecycle.
+These are certainly valid observations,
+and so pytm attempts to get threat modeling to 'shift-left' in the development lifecycle.
 
 Many traditional threat modeling tools such as OWASP Threat Dragon provide
 a graphical way of creating diagrams and entering threats.
@@ -55,7 +56,7 @@ This makes pytm a powerful tool for describing a system or application, and allo
 
 This focus on the model as code and programmatic outputs makes Pytm particularly useful in automated environments,
 helping the threat model to be built in to the design process from the start,
-as well as in the more traditional threat modeling sessions.
+as well as in more traditional threat modeling sessions.
 
 #### How to use pytm
 

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

@@ -1,6 +1,6 @@
 ---
 
-title: Threat Modeling with Threat Dragon
+title: Threat Dragon
 layout: col-document
 tags: OWASP Developer Guide
 contributors: Jon Gadsden
@@ -34,37 +34,34 @@ Threat Dragon aims for:
 
 * Simplicity - you can install and start using Threat Dragon very quickly
 * Flexibility - the diagramming and threat generation allows all types of threat to be described
-* Accessibility - different types of teams can benefit from Threat Dragon’s simplicity and flexibility
+* Accessibility - various different types of teams can all benefit from Threat Dragon ease of use
 
 It supports various methodologies and threat categorizations used during the threat modeling activities:
 
 * STRIDE
 * LINDDUN
+* PLOT4ai
 * CIA
 * DIE
 
-and it can be used by a wide range of developers and teams:
-
-* Simplicity - installation is easy and teams can start using Threat Dragon quickly
-* Flexibility - the diagramming and threat generation allows all types of threat to be described
-* Accessibility - various different types of teams can all benefit from Threat Dragon ease of use
+and it can be used by all sorts of development teams.
 
 #### How to use it
 
 The OWASP Spotlight series provides an overview of Threat Dragon and how to use it:
 'Project 22 - [OWASP Threat Dragon][spotlight22]'.
 
-Threat Dragon is distributed as a cross platform desktop application as well a web application.
 It is straightforward to start using Threat Dragon; the latest version is [available to use online][tddemo]:
 
-1. select Login to Local Session
-2. select Explore a Sample Threat Model
-3. select Version 2 Demo Model
-4. you are presented with the threat model meta-data which can be edited
-5. click on the diagram Main Request Data Flow to display the data flow diagram
+1. select 'Login to Local Session'
+2. select 'Explore a Sample Threat Model'
+3. select 'Version 2 Demo Model'
+4. you are then presented with the threat model meta-data which can be edited
+5. click on the diagram 'Main Request Data Flow' to display the data flow diagram
 6. the diagram components can be inspected, and their associated threats are displayed
 7. components can be added and deleted, along with editing their properties
 
+Threat Dragon is distributed as a cross platform desktop application as well a web application.
 The [desktop application][tddownload] can be downloaded for Windows, Linux and MacOS.
 The web application can be run using a [Docker container][tddocker] or from the [source code][tdcode].