various improvements to Foundations sections

Author: jgadsden

.wordlist.txt

@@ -473,4 +473,5 @@ MOBI
 linddun
 LINNDUN
 DPO
-CISO
+CISO
+iteratively

README.md

@@ -17,9 +17,8 @@ Note that the original DevGuide repository has been deprecated in favour of this
 
 The source for the latest draft developer guide can be found under the ['draft'][draft] directory.
 The source is in markdown and is used to create the developer guide HTML, PDF and ePub outputs.
-The content is subject to large scale changes with no notice,
-and is usually being actively worked on for the latest release
-of the Developer Guide under the ['release'][release] directory.
+The draft content is subject to large scale changes with no notice.
+The draft version is used for the Developer Guide in the ['release'][release] directory.
 
 ### Contributing
 

draft/03-introduction.md

@@ -25,35 +25,35 @@ Along with the OWASP Top Ten, the Developer Guide is one of the original resourc
 published soon after the OWASP foundation was formed in 2001.
 Version 1.0 of the Developer Guide was released in 2002
 and since then there have been various [releases][versions] culminating in version 2.0 in 2005.
-Since then the guide has been revised extensively to bring it up to date and no longer has version numbers;
-notionally it is version 4.x as version 3.0 was never released.
+Since then the guide has been revised extensively to bring it up to date.
+The latest versions are 4.x because version 3.0 was never released.
 
 The purpose of this guide is to provide an introduction to security concepts
 and a handy reference for application / system developers.
 Generally it describes security practices using the advice given in the
 OWASP Software Assurance Maturity Model ([SAMM][samm]) and describes the OWASP projects
 referenced in the OWASP [Application Wayfinder][wayfinder] project.
 
-The content of the Developer Guide is aimed at an introductory level, with more detail provided by each OWASP project.
 This guide does not seek to replicate the many excellent sources on specific security topics;
-it will rarely deal with a subject in depth and instead provides links for greater depth in these security topics.
+it will rarely tries to go into details on a subject and instead provides links for greater depth on these security topics.
+Instead the content of the Developer Guide aims to be accessible, introducing  practical security concepts
+and providing enough detail to get developers started on various OWASP tools and documents.
 
 All of the OWASP projects and tools described in this guide are free to download and use.
-All OWASP projects are open source, so if you are interested in improving application security then do get involved.
+All OWASP projects are open source; do get involved if you are interested in improving application security.
 
 #### Audience
 
 The OWASP Developer Guide has been written by the security community to help software developers write solid,
 safe and secure applications.
-Application developers should try to be familiar with the entire guide;
-it is far harder to write solid applications than to destroy them.
+Developers should try and be familiar with most of this guide; it will help to write solid applications.
 
 You can regard the purpose of this guide as answering the question:
  “I am a developer and I need a reference guide to describe the security activities I really should be doing
  and to navigate the numerous security tools and projects”
 
 Or you can regard this guide as a companion document to the OWASP [Application Wayfinder][wayfinder] project:
-the Wayfinder maps out the many OWASP tools, projects and documents with the Developer Guide providing some context.
+the Wayfinder mapping out the many OWASP tools, projects and documents with the Developer Guide providing some context.
 
 ![Application Wayfinder Diagram](../assets/images/owasp-wayfinder.png "OWASP Application Wayfinder")
 

draft/04-foundations/01-security-fundamentals.md

@@ -35,9 +35,9 @@ Often CIA is extended with AAA: Authorization, Authentication and Auditing.
 #### Confidentiality
 
 Confidentiality is the protection of data against unauthorized disclosure;
-it is about ensuring that only those with the correct authorization can access the data.
-Confidentiality applies to data at rest, and should also be considered for data in motion.
-Confidentiality is related to the broader concept of data privacy.
+it is about ensuring that only those with the correct authorization can access the data
+and applies to both data at rest and to data in transit.
+Confidentiality is also related to the broader concept of data privacy.
 
 #### Integrity
 
@@ -54,27 +54,29 @@ but also on the protection of the services that provide access to the data, for
 #### AAA
 
 CIA is often extended with Authentication, Authorization and Auditing as these are closely linked to CIA concepts.
-CIA has such a strong dependency on Authentication and Authorization
-that the confidentiality of the data in question can't be assured without them.
+CIA has a strong dependency on Authentication and Authorization;
+the confidentiality and integrity of sensitive data can not be assured without them.
 Auditing is added as it can provide the mechanism to ensure proof of any interaction with the system.
 
 #### Authentication
 
 Authentication is about confirming the identity of the entity that wants to interact with a secure system.
+For example the entity could be an automated client or a human actor;
+in either case authentication is required for a secure application.
 
 #### Authorization
 
 Authorization is about specifying access rights to secure resources (data, services, files, applications, etc).
-These rights describe the privileges or access levels related to the resources in question.
-It is normally preceded by *Authentication*.
+These rights describe the privileges or access levels related to the resources that are being secured.
+Authorization is usually preceded by successful authentication.
 
 #### Auditing
 
 Auditing is about keeping track of implementation-level events, as well as domain-level events taking place in a system.
 This helps to provide non-repudiation, which means that changes or actions on the protected system are undeniable.
 Auditing can provide not only technical information about the running system,
 but also proof that particular actions have been performed.
-The typical questions that are answered by auditing are "*Who* did *What* *When* and potentially *How*?"
+The typical questions that are answered by auditing are "Who did What, When and potentially How?"
 
 #### Software Assurance Maturity Model
 

draft/04-foundations/02-secure-development.md

@@ -30,26 +30,27 @@ according to the processes adopted by the business.
 
 With the increasing number and sophistication of exploits against almost every application or business system,
 most companies have adopted a secure Software Development LifeCycle (SDLC).
-The secure SDLC should never be a separate lifecycle,
-it must always be the same Software Development LifeCycle as before but with security actions built into each phase,
-otherwise the security actions will be set aside by busy development teams.
+The secure SDLC should never be a separate lifecycle from an existing software development lifecycle,
+it must always be the same development lifecycle as before but with security actions built into each phase,
+otherwise security actions may well be set aside by busy development teams.
 Note that although the Secure SDLC could be written as 'SSDLC' it is almost always written as 'SDLC'.
 
 DevOps integrates and automates many of the SDLC phases and implements Continuous Integration (CI)
-and Continuous Delivery/Deployment (CD) pipelines to provide much of this automation.
+and Continuous Delivery/Deployment (CD) pipelines to provide much of the SDLC automation.
+Examples of how DevSecOps is 'building security in' is the provision of
+Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST)
+and implementing supply chain security, and there are many other security activities that can be applied.
+
 DevOps and pipelines have been successfully exploited with serious large scale consequences
 and so, in a similar manner to the SDLC, much of the DevOps actions have also had to have security built in.
 Secure DevOps, or DevSecOps, builds security practices into the DevOps activities to guard against attack
 and to provide the SDLC with automated security testing.
-Examples of how DevSecOps is 'building security in' is the provision of
-Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST)
-and implementing supply chain security, and there are many other security activities that can be applied.
 
 #### Secure development lifecycle
 
 Referring to the OWASP [Application Wayfinder][wayfinder] development cycle
-there are four phases during application development: Requirements, Design, Implementation and Verification.
-There are other phases that are done less often in the development cycle and these form an equally important
+there are four iterative phases during application development: Requirements, Design, Implementation and Verification.
+The other phases are done less iteratively in the development cycle but these form an equally important
 part of the SDLC: Gap Analysis, Metrics, Operation and Training & Culture Building.
 
 All of these phases of the SDLC should have security activities built into them,
@@ -59,19 +60,19 @@ a process as before, with the development teams taking ownership of the security
 
 There are many OWASP tools and resources to help build security into the SDLC.
 
-* Requirements: this phase determines the functional, non-functional and security requirements for the application.
-    Requirements should be revisited periodically and check for completeness and validity,
-    and it is worth considering various OWASP tools;
-    the [Application Security Verification Standard (ASVS)][asvs] provides developers
-    with a list of requirements for secure development,
-    the [Mobile Application Security project][masproject] provides a security standard for mobile applications
-    and [SecurityRAT][srat] helps identify an initial set of security requirements.
+* **Requirements**: this phase determines the functional, non-functional and security requirements for the application.
+    Requirements should be revisited periodically and checked for completeness and validity,
+    and it is worth considering various OWASP tools to help with this;
+  * the [Application Security Verification Standard (ASVS)][asvs] provides developers
+      with a list of requirements for secure development,
+  * the [Mobile Application Security project][masproject] provides a security standard for mobile applications
+      and [SecurityRAT][srat] helps identify an initial set of security requirements.
 
-* Design: it is important to design security into the development - it is never too late to do this
-    but the earlier the better (and easier). OWASP provides two tools, [Pythonic Threat Modeling][pytm]
+* **Design**: it is important to design security into the application - it is never too late to do this
+    but the earlier the better and easier to do. OWASP provides two tools, [Pythonic Threat Modeling][pytm]
     and [Threat Dragon][tdtm], for threat modeling along with security gamification using [Cornucopia][cornucopia].
 
-* Implementation: the OWASP [Top 10 Proactive Controls][proactive10] project states that they are
+* **Implementation**: the OWASP [Top 10 Proactive Controls][proactive10] project states that they are
     "the most important control and control categories that every architect and developer should absolutely,
     100% include in every project" and this is certainly good advice. Implementing these controls can provide
     a high degree of confidence that the application or system will be reasonably secure.
@@ -81,47 +82,47 @@ There are many OWASP tools and resources to help build security into the SDLC.
     that help implement these proactive controls. In addition the OWASP [Cheat Sheet Series][cheatproject]
     is a valuable source of information and advice on all aspects of applications security.
 
-* Verification: OWASP provides a relatively large number of projects that help with testing and verification.
-   This is the subject of a section in this Developer Guide, and the projects are listed below.
+* **Verification**: OWASP provides a relatively large number of projects that help with testing and verification.
+   This is the subject of a section in this Developer Guide, and the projects are listed at the end of this section.
 
-* Training: development teams continually need security training. Although not part of the inner SDLC iterative loop,
-   training should be factored into the project lifecycle.
+* **Training**: development teams continually need security training.
+   Although not part of the inner SDLC iterative loop training should still be factored into the project lifecycle.
    OWASP provides many training environments and materials - see the list at the end of this section.
 
-* Culture Building: a good security culture within a business organization will help greatly in keeping
+* **Culture Building**: a good security culture within a business organization will help greatly in keeping
    the applications and systems secure. There are many activities that all add up to create the
    security culture, the OWASP [Security Culture][culture] project goes into more detail on these activities,
    and a good Security Champion program within the business is foundational to a good security posture.
    The OWASP [Security Champions Guide][champions] provides guidance and material to create security champions
    within the development teams - ideally every team should have a security champion that has
    a special interest in security and has received further training, enabling the team to build security in.
 
-* Operation: the OWASP [DevSecOps Guideline][devsecops] explains how to best implement a secure pipeline,
+* **Operation**: the OWASP [DevSecOps Guideline][devsecops] explains how to best implement a secure pipeline,
     using best practices and introducing automation tools to help 'shift-left'.
     Refer to the DevSecOps Guideline for more information on any of the topics within DevSecOps
     and in particular sections on Operation.
 
-* Supply chain: attacks that leverage the supply chain can be devastating
+* **Supply chain**: attacks that leverage the supply chain can be devastating
     and there have been several high profile of products being successfully exploited.
     A Software Bill of Materials (SBOM) is the first step in avoiding these attacks and
     it is well worth using the OWASP [CycloneDX][cyclone] full-stack Bill of Materials (BOM) standard
     for risk reduction in the supply chain.
     In addition the OWASP [Dependency-Track][deptrack] project is a Continuous SBOM Analysis Platform
     which can help prevent these supply chain exploits by providing control of the SBOM.
 
-* Third party libraries: keeping track of what third party libraries are included in the application,
+* **Third party dependencies**: keeping track of what third party libraries are included in the application,
     and what vulnerabilities they have, is easily automated. Many public repositories such as [github][github]
     and [gitlab][gitlab] offer this service along with some commercial vendors.
     OWASP provides the [Dependency-Check][depcheck] Software Composition Analysis (SCA) tool
     to track external libraries.
 
-* Application security testing: there are various types of security testing that can be automated on pull-request,
+* **Application security testing**: there are various types of security testing that can be automated on pull-request,
    merge or nightlies - or indeed manually but they are most powerful when automated. Commonly there is
    Static Application Security Testing (SAST), which analyses the code without running it,
-   Dynamic Application Security Testing (DAST), which applies input to the application while running it in a sandbox
-   or other isolated environment.
-   Interactive Application Security Testing (IAST) on the other hand is designed to be run manually as well,
-   providing instant feedback on the tests as they are run.
+   and Dynamic Application Security Testing (DAST), which applies input to the application while running it in a sandbox
+   or other isolated environments.
+   Interactive Application Security Testing (IAST) is designed to be run manually as well as being automated,
+   and provides instant feedback on the tests as they are run.
 
 #### Further reading from OWASP