Merge pull request #14 from devsecopsmaturitymodel/feat/descriptions-enhancement

wurstbrot · web-flow · commit e462bb575758 · 2025-02-23T16:17:06.000+01:00
feat: enhance descriptions
diff --git a/Dockerfile b/Dockerfile
@@ -12,5 +12,6 @@ RUN cd /var/www/html/yaml-generation && composer install \
 RUN pecl channel-update pecl.php.net && pecl install yaml && docker-php-ext-enable yaml
 RUN curl https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/refs/heads/master/src/assets/YAML/meta.yaml -o /var/www/html/src/assets/YAML/meta.yaml
 RUN cd /var/www/html && php yaml-generation/generateDimensions.php
+RUN curl https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/refs/heads/master/src/assets/YAML/meta.yaml -o /var/www/html/src/assets/YAML/meta.yaml
 workdir /var/www/html
 CMD php yaml-generation/generateDimensions.php
diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml
@@ -41,16 +41,20 @@ Build and Deployment:
       comments: ""
     Defined build process:
       uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b
+      description: |
+        A *build process* include more than just compiling your source code. 
+        It also includes steps such as managing (third party) dependencies, 
+        environment configuration, running the unit tests, etc. 
+        
+        A *defined build process* has automated these steps to ensure consistency.
+
+        This can be done with a Jenkinsfile, Maven, or similar tools.
       risk:
         Performing builds without a defined process is error prone; for example,
         as a result of incorrect security related configuration.
       measure:
         A well defined build process lowers the possibility of errors during
         the build process.
-      description: |
-        Sample evidence as an attribute in the yaml: The build process is defined in [REPLACE-ME Pipeline](https://replace-me/jenkins/job)
-        in the folder _vars_. Projects are using a _Jenkinsfile_ to use the
-        defined process.
       difficultyOfImplementation:
         knowledge: 2
         time: 3
diff --git a/src/assets/YAML/default/CultureAndOrganization/Process.yaml b/src/assets/YAML/default/CultureAndOrganization/Process.yaml
@@ -58,15 +58,18 @@ Culture and Organization:
       comments: ""
     Definition of simple BCDR practices for critical components:
       uuid: c72da779-86cc-45b1-a339-190ce5093171
+      description:
+        A _Business Continuity and Disaster Recovery_ (BCDR) is a plan and a process
+        that helps a business to return to normal operations if a disaster occurs.
       risk:
-        In case of an emergency, like a power outage, DR actions to perform are
-        not clear. This leads to reaction and remediation delays.
+        If the disaster recovery actions are not clear, you risk slow reaction and remediation delays.
+        This applies to cyber attacks as well as natural emergencies, such as a power outage.
       measure:
         By understanding and documenting a business continuity and disaster
         recovery (BCDR) plan, the overall availability of systems and applications
         is increased. Success factors like responsibilities, Service Level Agreements,
         Recovery Point Objectives, Recovery Time Objectives or Failover must be fully
-        documented and understood.
+        documented and understood by the people involved in the recovery.
       difficultyOfImplementation:
         knowledge: 4
         time: 3
diff --git a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml
@@ -49,23 +49,79 @@ Implementation:
         iso27001-2022:
           - Hardening is not explicitly covered by ISO 27001 - too specific
           - 8.22
-      isImplemented: false
       comments: ""
-    Contextualized Encoding:
+    Context-aware output encoding:
       uuid: e1f37abb-d848-4a3a-b3df-65e91a89dcb7
+      description: |
+        **Input validation** stops malicious data from entering your system. \
+        **Output encoding** neutralizes malicious data before rendering to user, or the next system.
+
+        Input validation and output encoding work together. Apply both. 
+
+        **Context-aware output encoding** encodes data differently, depending on its context. In the sample below the `{{bad_data}}` must be encoded differently, depending on its context, to render safe HTML.
+
+        ```html
+        <div>{{bad_data}}</div>
+        <a href="{{bad_data}}">Click me</a>
+        <script>var x = '{{bad_data}}';</script>
+        <script>/** Comment {{bad_data}} */</script>
+        ```                
       risk:
-        The generation of interpreter directives from user-provided data poses difficulties and can introduce vulnerabilities to injection attacks.
+        If an attacker manages to slip though your input validation, the attacker may gain control over the user session or execute arbitrary actions.
       measure: |
-        Implementing contextualized encoding, such as employing object-relational mapping tools or utilizing prepared statements, nearly removes the threat of injection vulnerabilities.
+        * Use modern secure frameworks such as React/Angular/Vue/Svelte. The default method here renders data in a safe way.
+        * Use established and well-maintained encoding libraries such as OWASP’s Java Encoder and Microsoft’s AntiXSS.
+        * Implement content security policies (CSP) to restrict the types of content that can be loaded and executed.
       difficultyOfImplementation:
-        knowledge: 2
+        knowledge: 1
         time: 2
         resources: 1
       usefulness: 3
       level: 1
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-dom-xss-cheats
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/cwe-838
+      references:
+        samm2:
+          - D-SR-1-A
+        iso27001-2017:
+          - Hardening is not explicitly covered by ISO 27001 - too specific
+          - 13.1.3
+        iso27001-2022:
+          - Hardening is not explicitly covered by ISO 27001 - too specific
+          - 8.22
+      comments: ""
+    Parametrization:
+      uuid: 00e91a8a-3972-4692-8679-674ab8547486
       description: |
-        Bear in mind that utilizing frameworks is a recommended approach; however, they can develop known security weaknesses over time. Diligent and regular patching is crucial.
-      implementation: []
+        By concatenating strings from user input to build SQL queries, an attacker can manipulate the query to do other unintentional SQL commands as well.
+
+        This is called *SQL injection* but the principle applies to NoSql, and anywhere that your code is building commands that will be executed.
+
+        Pay attention to these two lines of code. They seem similar, but behave very differently.
+
+          * `sql.execute("SELECT * FROM table WHERE ID = " + id);`
+          * `sql.execute("SELECT * FROM table WHERE ID = ?", id);`
+        The second line is parameterized. The same principle applies to other types, such as command line execution, etc.
+      risk: |
+        Systems vulnerable to injections may lead to data breaches, loss of data, 
+        unauthorized alteration of data, or complete database compromise or downtime.
+
+        This applies to SQL, NoSql, LDAP, XPath, email headers OS commands, etc. 
+      measure: |
+        * Identify which of the types your application is using. Check that you use:
+          * Use _parametrized queries_ (or _prepared statements_)
+        * For database queries, you may also use:
+          * Use _stored procedures_ ()
+          * Use ORM (Object-Relational Mapping) tools that automatically handle input sanitization
+      difficultyOfImplementation:
+        knowledge: 1
+        time: 2
+        resources: 1
+      usefulness: 3
+      level: 1
+      implementation: 
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-parameterization-cheats
       references:
         samm2:
           - D-SR-1-A
@@ -75,6 +131,7 @@ Implementation:
         iso27001-2022:
           - Hardening is not explicitly covered by ISO 27001 - too specific
           - 8.22
+      comments: ""
     App. Hardening Level 1:
       uuid: cf819225-30cb-4702-8e32-60225eedc33d
       risk:
@@ -155,7 +212,6 @@ Implementation:
           - Hardening is not explicitly covered by ISO 27001 - too specific
           - 8.22
       isImplemented: false
-      evidence: ""
       comments: ""
       dependsOn:
         - App. Hardening Level 1
@@ -189,7 +245,6 @@ Implementation:
           - Hardening is not explicitly covered by ISO 27001 - too specific
           - 8.22
       isImplemented: false
-      evidence: ""
       comments: ""
       dependsOn:
         - App. Hardening Level 2 (75%)
diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml
@@ -510,10 +510,12 @@ Implementation:
       uuid: ad23be9c-5661-4f1f-81a3-5a5dc7061629
       risk:
         Evil actors might be able to perform a man in the middle attack and sniff
-        confidential information (e.g. authentication factors like passwords)
-      measure:
+        confidential information (e.g. authentication factors like passwords).
+      measure: |-
         By using encryption at the edge of traffic in transit, it is impossible
-        or at least harder to sniff credentials being outside of the organization.
+        or at least harder to sniff credentials or information being outside of the organization.
+      
+        Using standard secure protocols like HTTPS is recommended.
       difficultyOfImplementation:
         knowledge: 2
         time: 2
@@ -699,7 +701,7 @@ Implementation:
       description: |
         Begin with the WAF in a monitoring state to understand the traffic and threats. Progressively enforce blocking actions based on intelligence gathered, ensuring minimal disruption to legitimate traffic.
       dependsOn:
-        - Contextualized encoding
+        - Context-aware output encoding
       implementation: []
       references:
         samm2:
diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml
@@ -291,15 +291,23 @@ Information Gathering:
         iso27001-2022:
           - Not explicitly covered by ISO 27001 - too specific
           - 5.26
-      isImplemented: false
-      evidence: ""
       comments: ""
     Simple application metrics:
       uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1
       risk: Attacks on an application are not recognized.
-      measure:
-        Gathering of application metrics helps to identify incidents like brute
-        force attacks, login/logout.
+      measure: |-
+        Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include:
+          - Authentication attempts (successful/failed logins)
+          - Transaction volumes and patterns (e.g. orders, payments)
+          - API call rates and response times
+          - User session metrics
+          - Resource utilization
+        
+        Example: An e-commerce application normally processes 100 orders per hour. A sudden spike to 1000 orders per hour could indicate either:
+         - A legitimate event (unannounced marketing campaign, viral social media post)
+         - A security incident (automated bulk purchase bots, credential stuffing attack)
+        
+        By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response.
       difficultyOfImplementation:
         knowledge: 2
         time: 2
@@ -315,8 +323,6 @@ Information Gathering:
           - 12.4.1
         iso27001-2022:
           - 8.15
-      isImplemented: false
-      evidence: ""
       comments: ""
     Simple budget metrics:
       uuid: f08a3219-6941-43ec-8762-4aff739f4664
diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml
@@ -21,38 +21,9 @@ Test and Verification:
           - The number of network hops required to reach the asset (recommended)
           - Authentication requirements for access (recommended)
       dependsOn:
-        - uuid:38d1bd10-7b5f-4ae1-868c-0ec813285425 # Fix based on severity
+        - uuid:44f2c8a9-4aaa-4c72-942d-63f78b89f385 # Treatment of defects with severity high or higher:
         #- uuid:3260a15f-2df0-4173-8790-f11de2cb525a # Access applications accessibility TODO
-        - uuid:2a44b708-734f-4463-b0cb-86dc46344b2f #iventory of apps
-      implementation:
-      references:
-        samm2:
-          - I-DM-3-B
-        iso27001-2017:
-          - 16.1.4
-          - 8.2.1
-          - 8.2.2
-          - 8.2.3
-        iso27001-2022:
-          - 5.25
-          - 5.12
-          - 5.13
-          - 5.10
-      tags: ["vuln-action", "defect-management"]
-    Fix based on severity:
-      uuid: 38d1bd10-7b5f-4ae1-868c-0ec813285425
-      risk: |-
-        Overwhelming volume of security findings from automated testing tools. This might lead to ignorance of findings.
-      measure: |
-       Implement a very simple risk-based prioritization framework for vulnerability remediation based on the severity of the findings.
-       
-       On level one, fix only critical findings.
-      difficultyOfImplementation:
-        knowledge: 2
-        time: 2
-        resources: 1
-      usefulness: 3
-      level: 1
+        - uuid:2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components
       implementation:
       references:
         samm2:
@@ -168,11 +139,19 @@ Test and Verification:
       uuid: c1acc8af-312e-4503-a817-a26220c993a0
       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.
-        A Vulnerability Management System might be used.
+        ignored. Specially, if tests are automated an run daily.
+      measure: |-
+        Findings from security tests must be triaged and outcomes persisted/documented to:
+          - Prevent re-analysis of known issues in subsequent test runs
+          - Track accepted risks vs false positives
+          - Enable consistent decision-making across teams
+        
+        At this maturity level, a simple tracking system suffices - tools need only distinguish between "triaged" and "untriaged" findings, without complex categorization. Some tools refer to this as "suppression" of findings.
+        
+        Samples for false positive handling:
+          - [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html)
+          - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/)
+          - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status)
       difficultyOfImplementation:
         knowledge: 1
         time: 1
@@ -248,8 +227,7 @@ Test and Verification:
         iso27001-2022:
           - 8.8
           - 5.25
-      isImplemented: false
-      evidence: ""
+      tags: ["vuln-action", "defect-management"]
       comments: ""
     Treatment of defects with severity high or higher:
       uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385
@@ -274,7 +252,7 @@ Test and Verification:
           - 8.8
           - 5.25
       implementation: []
-      isImplemented: false
+      tags: ["vuln-action", "defect-management"]
       evidence: ""
     Treatment of defects with severity middle:
       uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594
@@ -297,6 +275,7 @@ Test and Verification:
           - 8.8
           - 5.25
       implementation: []
+      tags: ["vuln-action", "defect-management"]
     Usage of a vulnerability management system:
       uuid: 85ba5623-84be-4219-8892-808837be582d
       risk:
diff --git a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml
@@ -70,7 +70,7 @@ Test and Verification:
       risk:
         Time pressure and ignorance might lead to false predictions for the test
         intensity.
-      measure: The intensity of the used tools are not modified to safe time.
+      measure: The intensity of the used tools are not modified to save time.
       difficultyOfImplementation:
         knowledge: 1
         time: 1
diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml
@@ -41,6 +41,11 @@ implementations:
     name: CWE Top 25 Most Dangerous Software Weaknesses
     tags: ["documentation", "threat"]
     url: https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html
+  cwe-838:
+    uuid: ae97c9b0-308c-4dab-bff9-bf3330a897dc
+    name: CWE-838 Inappropriate Encoding for Output Context
+    tags: ["documentation", "cwe"]
+    url: https://cwe.mitre.org/data/definitions/838.html
   docker-content-trust:
     uuid: ee81f93f-8230-4cfb-a132-ae4ec61cb8e6
     name: Docker Content Trust
@@ -430,6 +435,16 @@ implementations:
     name: OWASP Logging CheatSheet
     url: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
     tags: [logging, documentation]
+  owasp-dom-xss-cheats:
+    uuid: 2d61e48f-bade-4332-a383-adc50c29673a
+    name: OWASP DOM based XSS Prevention CheatSheet
+    url: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
+    tags: []
+  owasp-parameterization-cheats:
+    uuid: d880fa0f-9dbb-454e-a003-d844fad31ab4
+    name: OWASP Parameterization CheatSheet
+    url: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html
+    tags: []
   elk-stack:
     uuid: 38fe9d00-df8b-44b6-910d-ca0f02b5c5d3
     name: ELK-Stack
diff --git a/src/assets/YAML/schemas/dsomm-schema-implementation.json b/src/assets/YAML/schemas/dsomm-schema-implementation.json
@@ -135,11 +135,17 @@
                     "iso27001-2022"
                   ]
                 },
-                "isImplemented": {
-                  "type": "boolean"
+                "teamsImplemented": {
+                  "type": "array",
+                  "items": {
+                    "type": "object"
+                  }
                 },
-                "evidence": {
-                  "type": "string"
+                "teamsEvidence": {
+                  "type": "array",
+                  "items": {
+                    "type": "object"
+                  }
                 },
                 "comments": {
                   "type": "string"
@@ -155,8 +161,6 @@
                 "level",
                 "implementation",
                 "references",
-                "isImplemented",
-                "evidence",
                 "comments"
               ],
               "additionalProperties": false
