Merge pull request #74 from MagnificRogue/magnificrogue/aspell-check

Manually run Aspell Check

Author: wurstbrot

data-new/BuildAndDeployment/Sub-Dimensions.yaml

@@ -22,8 +22,8 @@ Build:
     measure: Each step during within the build and testing phase is performed in
       a separate virtual environments, which is destroyed afterward.
     meta:
-      implementationGuide: Depending on your envirnoment, usage of virtual machines
-        or container technoligy is a good way. After the build, the filesystem should
+      implementationGuide: Depending on your environment, usage of virtual machines
+        or container technology is a good way. After the build, the filesystem should
         not be used again in other builds.
     difficultyOfImplementation:
       knowledge: 2
@@ -278,7 +278,7 @@ Deployment:
     - 12.1.4
   Usage of trusted images:
     risk: Developers or operations might start random images in the production cluster
-      which have malicous code or known vulnerabilities.
+      which have malicious code or known vulnerabilities.
     measure: Create image assessment criteria, perform an evaluation of images and
       create a whitelist of artifacts/container images/virtual machine images.
     implementation: Kubernetes Admission Controller can whitelist registries and/or
@@ -300,7 +300,7 @@ Deployment:
       to be known where an artifacts with that vulnerability is deployed with which
       dependencies.
     measure: A documented inventory or a possibility to gather the needed information
-      (e.g. the documentation of which script needs to be run by whoom) must be
+      (e.g. the documentation of which script needs to be run by whom) must be
       in place.
     dependsOn:
     - Defined deployment process
@@ -347,7 +347,7 @@ Patch Management:
     risk: Known vulnerabilities components might stay for long and get exploited,
       even when a patch is available.
     measure: Fast patching of third party component is needed. The DevOps way is
-      to have an automated pull request for new components. This includes <ul> <li>Applications</li><li>Virutalized
+      to have an automated pull request for new components. This includes <ul> <li>Applications</li><li>Virtualized
       operating system components (e.g. container images)</li> <li>Operating Systems</li><li>Infrastructure
       as Code/GitOps (e.g. argocd)</li> </ul>
     difficultyOfImplementation:

data-new/CultureAndOrganization/Design.yaml

@@ -1,8 +1,8 @@
 ---
 Design:
-  Conduction of advanced threat modelling:
+  Conduction of advanced threat modeling:
     risk: Inadequate identification of business and technical risks.
-    measure: Threat modelling is performed by using reviewing user stories and producing
+    measure: Threat modeling is performed by using reviewing user stories and producing
       security driven data flow diagrams.
     difficultyOfImplementation:
       knowledge: 4
@@ -29,10 +29,10 @@ Design:
     - may be part of risk assessment
     - 8.2.1
     - 14.2.1
-  Conduction of simple threat modelling on business level:
+  Conduction of simple threat modeling on business level:
     risk: Business related threats are discovered too late in the development and
       deployment process.
-    measure: Threat modelling of business functionality is performed during the product
+    measure: Threat modeling of business functionality is performed during the product
       backlog creation to facilitate early detection of security defects.
     difficultyOfImplementation:
       knowledge: 2
@@ -46,10 +46,10 @@ Design:
     - may be part of risk assessment
     - 8.2.1
     - 14.2.1
-  Conduction of simple threat modelling on technical level:
+  Conduction of simple threat modeling on technical level:
     risk: Technical related threats are discovered too late in the development and
       deployment process.
-    measure: Threat modelling of technical features is performed during the product
+    measure: Threat modeling of technical features is performed during the product
       sprint planning.
     difficultyOfImplementation:
       knowledge: 2
@@ -58,7 +58,7 @@ Design:
     usefulness: 3
     level: 1
     implementation:
-    - <a href="https://github.com/Toreon/threat-model-playbook">Threat modelling Playbook</a>
+    - <a href="https://github.com/Toreon/threat-model-playbook">Threat modeling Playbook</a>
     md-description: |2
 
       Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage.
@@ -75,7 +75,7 @@ Design:
 
         ![Threat Model](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/threat_model.png "Threat Model")
 
-        Last, if the organisation maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function.
+        Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function.
 
         ![SKF](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/skf_qs.png "SKF")
 
@@ -104,7 +104,7 @@ Design:
     risk: Simple user stories are not going deep enough. Relevant security considerations
       are performed. Security flaws are discovered too late in the development and
       deployment process
-    measure: Advanced abuse stories are created as part of threat modelling activities.
+    measure: Advanced abuse stories are created as part of threat modeling activities.
     difficultyOfImplementation:
       knowledge: 4
       time: 2
@@ -118,7 +118,7 @@ Design:
     - not explicitly covered by ISO 27001
     - may be part of project management
     - 6.1.5
-    - may be part of risk assesment
+    - may be part of risk assessment
     - 8.1.2
     implementation: <a href='https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories'>Don't
       Forget EVIL User Stories</a> and <a href='http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf'>Practical
@@ -138,13 +138,13 @@ Design:
     - not explicitly covered by ISO 27001
     - may be part of project management
     - 6.1.5
-    - may be part of risk assesment
+    - may be part of risk assessment
     - 8.1.2
     implementation: <a href='https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories'>Don't
       Forget EVIL User Stories</a> and <a href='http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf'>Practical
       Security Stories and Security Tasks for Agile Development Environments</a>
   Information security targets are communicated:
-    risk: Employees don't known their organisation security targets. Therefore security
+    risk: Employees don't known their organizations security targets. Therefore security
       is not considered during development and administration as much as it should
       be.
     measure: Transparent and timely communication of the security targets by senior

data-new/CultureAndOrganization/EducationAndGuidance.yaml

@@ -83,7 +83,7 @@ Education and Guidance:
     samm: EG2-B
     iso27001-2017:
     - 7.2.2
-    implementation: Often, external employees are not invited for interal trainings.
+    implementation: Often, external employees are not invited for internal trainings.
       This activity focuses on providing security trainings to internal as well as
       external employees. It is conducted every two weeks for around one hour.
   Each team has a security champion:
@@ -138,7 +138,7 @@ Education and Guidance:
     - 12.7.1
   Conduction of collaborative team security checks:
     risk: Development teams limited insight over security practices.
-    measure: Mutual security testing the security of other teams's project enhances
+    measure: Mutual security testing the security of other teams project enhances
       security awareness and knowledge.
     difficultyOfImplementation:
       resources: 2
@@ -148,7 +148,7 @@ Education and Guidance:
     level: 4
     samm: EG2-A
     iso27001-2017:
-    - Mutual scurity testing is not explicitly required in ISO 27001 may be
+    - Mutual security testing is not explicitly required in ISO 27001 may be
     - 7.2.2
   Conduction of build-it, break-it, fix-it contests:
     risk: Understanding security is hard, even for security champions and the conduction
@@ -184,7 +184,7 @@ Education and Guidance:
     - 16.1.5
   Reward of good communication:
     risk: Employees are not getting excited about security.
-    measure: Good communication and transparency encourages cross-organisational support.
+    measure: Good communication and transparency encourages cross-organizational support.
       Gamification of security is also known to help, examples include T-Shirts, mugs,
       cups, giftcards and 'High-Fives'.
     difficultyOfImplementation:

data-new/Implementation/ApplicationHardening.yaml

@@ -27,11 +27,11 @@ Application Hardening:
 
       ![SAMM Requirements](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/OWASP-in0.png)
 
-      Organisations can use these to add solid security considerations at the start of the Software Development or Procurement process.
+      Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process.
 
       These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations.
 
-      In case of internal development and if the organisation maps Features to Epics, the [Security Knowledge Framework](https://securityknowledgeframework.org/) can be used to facilitate this process by leveraging its questionnaire function, shown below.
+      In case of internal development and if the organization maps Features to Epics, the [Security Knowledge Framework](https://securityknowledgeframework.org/) can be used to facilitate this process by leveraging its questionnaire function, shown below.
 
       Source: [OWASP Project Integration](https://raw.githubusercontent.com/OWASP/www-project-integration-standards/master/writeups/owasp_in_sdlc/index.md)
     implementation:

data-new/Implementation/InfrastructureHardening.yaml

@@ -4,7 +4,7 @@ Infrastructure Hardening:
     risk: Using default configurations for a cluster environment leads to potential
       risks.
     measure: Harden cluster environments according to best practices. Level 1 and
-      partiually level 2 from hardening practices like 'CIS Kubernetes Bench for Security'
+      partially level 2 from hardening practices like 'CIS Kubernetes Bench for Security'
       should considered.
     difficultyOfImplementation:
       knowledge: 4
@@ -75,8 +75,8 @@ Infrastructure Hardening:
     - 13.1.3
   Filter outgoing traffic:
     risk: A compromised infrastructure component might try to send out stolen data.
-    measure: Having a whitelist and explizitly allowing egress traffic provides the
-      ability to stop unauthorized data leackage.
+    measure: Having a whitelist and explicitly allowing egress traffic provides the
+      ability to stop unauthorized data leakage.
     difficultyOfImplementation:
       knowledge: 3
       time: 3
@@ -123,7 +123,7 @@ Infrastructure Hardening:
     implementation: seccomp, strace
     samm2: o-environment-management|A|1
     iso27001-2017:
-    - system hardenong is not explicitly covered by ISO 27001 - too specific
+    - system hardening is not explicitly covered by ISO 27001 - too specific
   Immutable Infrastructure:
     risk: The availability of IT systems might be disturbed due to components failures
     measure: Redundancies in the IT systems
@@ -231,7 +231,7 @@ Infrastructure Hardening:
     iso27001-2017:
     - 9.4.1
   Usage of a chaos monkey:
-    risk: Due to manuel changes on a system, they are not replaceable anymore. In
+    risk: Due to manual changes on a system, they are not replaceable anymore. In
       case of a crash it might happen that a planned redundant system is unavailable.
       In addition, it is hard to replay manual changes.
     measure: A randomized periodically shutdown of systems makes sure, that nobody
@@ -266,7 +266,7 @@ Infrastructure Hardening:
     - not explicitly covered by ISO 27001 - too specific
   Usage of test and production environments:
     risk: Security tests are not running regularly because test environments are missing
-    measure: A production and a production like envirnoment is used
+    measure: A production and a production like environment is used
     difficultyOfImplementation:
       knowledge: 3
       time: 3

data-new/InformationGathering/Logging.yaml

@@ -37,7 +37,7 @@ Logging:
     - 12.4.1
     - 18.1.1
   Logging of security events:
-    risk: No track of security-relevant events makes it harder to analyse an incident.
+    risk: No track of security-relevant events makes it harder to analyze an incident.
     measure: Security-relevant events like login/logout or creation, change, deletion
       of users should be logged.
     difficultyOfImplementation:
@@ -73,7 +73,7 @@ Logging:
     risk: Detection of security related events with hints on different systems/tools/metrics
       is not possible.
     measure: Events are correlated on one system. For example the correlation and
-      visualisation of failed login attempts combined with successful login attempts.
+      visualization of failed login attempts combined with successful login attempts.
     difficultyOfImplementation:
       knowledge: 4
       time: 4

data-new/InformationGathering/Monitoring.yaml

@@ -1,6 +1,6 @@
 ---
 Monitoring:
-  Advanced availablity and stability metrics:
+  Advanced availability and stability metrics:
     risk: Trends and advanced attacks are not detected.
     measure: Advanced metrics are gathered in relation to availability and stability.
       For example unplanned downtime's per year.
@@ -33,7 +33,7 @@ Monitoring:
     iso27001-2017:
     - 12.6.1
   Alerting:
-    risk: Incidents are discovered after they happend.
+    risk: Incidents are discovered after they happened.
     measure: |
       Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically.
     difficultyOfImplementation:
@@ -86,11 +86,11 @@ Monitoring:
     iso27001-2017:
     - not explicitly covered by ISO 27001 - too specific
     - 12.1.3
-  Defence metrics:
+  Defense metrics:
     risk: IDS/IPS systems like packet- or application-firewalls detect and prevent
       attacks. It is not known how many attacks has been detected and blocked.
     measure: |
-      Gathering of defence metrics like TCP/UDP sources enables to assume the geographic location of the request.
+      Gathering of defense metrics like TCP/UDP sources enables to assume the geographic location of the request.
       Assuming a Kubernetes cluster with an egress-traffic filter (e.g. IP/domain based), an alert might be send out in case of every violation. For ingress-traffic, alerting might not even be considered.
     difficultyOfImplementation:
       knowledge: 3
@@ -100,7 +100,7 @@ Monitoring:
     level: 4
     dependsOn:
     - Visualized metrics
-    - Filter outcoing traffic
+    - Filter outgoing traffic
     samm2: o-incident-management|A|2
     iso27001-2017:
     - 12.4.1
@@ -165,7 +165,7 @@ Monitoring:
   Simple system metrics:
     risk: Without simple metrics analysis of incidents are hard. In case an application
       uses a lot of CPU from time to time, it is hard for a developer to find out
-      the source with linux commands.
+      the source with Linux commands.
     measure: Gathering of system metrics helps to identify incidents and specially
       bottlenecks like in CPU usage, memory usage and hard disk usage.
     difficultyOfImplementation:
@@ -174,7 +174,7 @@ Monitoring:
       resources: 2
     usefulness: 5
     level: 1
-    implementation: collectd
+    implementation: collected
     samm2: o-incident-management|A|1
     iso27001-2017:
     - 12.1.3

data-new/TestAndVerification/Consolidation.yaml

@@ -23,7 +23,7 @@ Consolidation:
     risk: Improper examination of vulnerabilities leads to no visibility at all.
     measure: Quality gates for found vulnerabilities are defined. In the start it
       is important to not overload the security analyst, therefore the recommendation
-      is to start with alerting of high cirital vulnerabilities.
+      is to start with alerting of high critical vulnerabilities.
     difficultyOfImplementation:
       knowledge: 1
       time: 1
@@ -79,7 +79,7 @@ Consolidation:
     - 8.2.2
     - 8.2.3
   Simple false positive treatment:
-    risk: As false positive occure during each test, all vulnerabilities might be
+    risk: As false positive occur during each test, all vulnerabilities might be
       ignored.
     measure: False positives are suppressed so they will not show up on the next tests
       again. Most security tools have the possibility to suppress false positives.

data-new/TestAndVerification/DynamicDepthForInfrastructure.yaml

@@ -52,18 +52,18 @@ Dynamic depth for infrastructure:
     iso27001-2017:
     - 9.4.3
   Test network segmentation:
-    risk: Wrong or no network segmentation of pods makes it easyer for an attacker
+    risk: Wrong or no network segmentation of pods makes it easier for an attacker
       to access a database and extract or modify data.
-    measure: Cluster interal test needs to be performed. Integration of fine granulated
-      network segmenation (also between pods in the same namespace).
+    measure: Cluster internal test needs to be performed. Integration of fine granulated
+      network segmentation (also between pods in the same namespace).
     difficultyOfImplementation:
       knowledge: 2
       time: 2
       resources: 1
     usefulness: 3
     level: 2
     implementation: <a href="https://github.com/controlplaneio/netassert">netassert</a>
-    dependendsOn: Segmented networks for virtual environments
+    dependsOn: Segmented networks for virtual environments
     samm2: v-security-testing|A|2
     iso27001-2017:
     - 13.1.3
@@ -72,7 +72,7 @@ Dynamic depth for infrastructure:
   Test for exposed services:
     risk: Standard network segmentation and firewalling has not been performed, leading
       to world open cluster management ports.
-    measure: With the help of tools the network configuration of unintenonal exposed
+    measure: With the help of tools the network configuration of unintentional exposed
       cluster(s) are tested. To identify clusters, all subdomains might need to be
       identified with a tool like OWASP Amass to perform portscans based o the result.
     difficultyOfImplementation:

data-new/TestAndVerification/StaticDepthForApplications.yaml

@@ -138,9 +138,9 @@ Static depth for applications:
     samm2: v-security-testing|A|2
     iso27001-2017:
     - 12.6.1
-  Usage of multiple analysers:
-    risk: Each vulnerability analyser has different opportunities. By using just one
-      analyser, some vulnerabilities might not be found.
+  Usage of multiple analyzers:
+    risk: Each vulnerability analyzer has different opportunities. By using just one
+      analyzer, some vulnerabilities might not be found.
     measure: Usage of multiple static tools to find more vulnerabilities.
     difficultyOfImplementation:
       knowledge: 3