Fix: #70. Structured implementation fields.

Author: ioggstream

data-new/BuildAndDeployment/Sub-Dimensions.yaml

@@ -5,7 +5,11 @@ _meta:
     A markdown description of this dimension.
 _yaml_references:
   tools:
-    ci-cd: &ci-cd CI/CD tools, eg. Jenkins
+    ci-cd: &ci-cd
+      name: CI/CD tools
+      tags: [ci-cd]
+      description: |-
+        CI/CD tools such as jenkins, gitlab-ci or github-actions
 
 Build:
   Building and testing of artifacts in virtual environments:
@@ -31,8 +35,10 @@ Build:
     usefulness: 2
     level: 2
     implementation:
-    - Container technologies and orchestration like Docker, Kubernetes
-    - *ci-cd
+    - name: Container technologies and orchestration like Docker, Kubernetes
+      tags: []
+    - name: CI/CD tools, eg. Jenkins
+      tags: []
     references:
       samm2:
       - i-secure-build|A|2
@@ -55,7 +61,8 @@ Build:
     level: 1
     implementation:
     - *ci-cd
-    - Container technologies and orchestration like Docker, Kubernetes
+    - name: Container technologies and orchestration like Docker, Kubernetes
+      tags: []
     references:
       samm2:
       - i-secure-build|A|1
@@ -94,8 +101,12 @@ Build:
     usefulness: 4
     level: 3
     implementation:
-    - <a href="https://docs.docker.com/notary/getting_started/">Docker Content Trust</a>
-    - <a href="https://in-toto.github.io/">in-toto</a>
+    - name: Docker Content Trust
+      tags: []
+      url: https://docs.docker.com/notary/getting_started/
+    - name: in-toto
+      tags: []
+      url: https://in-toto.github.io/
     dependsOn:
     - Defined build process
     references:
@@ -119,8 +130,11 @@ Deployment:
     usefulness: 4
     level: 2
     implementation:
-    - A complete database backup might be performed*. For large and complex environments
-    - ' a Point in Time Recovery for databases should be implemented.'
+    - name: A complete database backup might be performed*. For large and complex
+        environments
+      tags: []
+    - name: a Point in Time Recovery for databases should be implemented.
+      tags: []
     dependsOn:
     - Defined deployment process
     references:
@@ -144,8 +158,9 @@ Deployment:
     usefulness: 2
     level: 4
     implementation:
-    - <a href='https://martinfowler.com/bliki/BlueGreenDeployment.html'>Blue/Green
-      Deployments</a>
+    - name: Blue/Green Deployments
+      tags: []
+      url: https://martinfowler.com/bliki/BlueGreenDeployment.html
     dependsOn:
     - Smoke Test
     references:
@@ -171,8 +186,9 @@ Deployment:
     usefulness: 4
     level: 1
     implementation:
-    - Jenkins
-    - ' Docker'
+    - *ci-cd
+    - name: Docker
+      tags: []
     references:
       samm2: i-secure-deployment|A|1
       iso27001-2017:
@@ -238,9 +254,12 @@ Deployment:
     usefulness: 2
     level: 3
     implementation:
-    - Docker
-    - ' Webserver'
-    - ' rolling update'
+    - name: Docker
+      tags: []
+    - name: Webserver
+      tags: []
+    - name: rolling update
+      tags: []
     dependsOn:
     - Defined deployment process
     samm2: i-secure-deployment|A|1
@@ -261,7 +280,8 @@ Deployment:
     usefulness: 4
     level: 3
     implementation:
-    - Docker
+    - name: Docker
+      tags: []
     dependsOn:
     - Defined build process
     samm: OE2-A
@@ -284,7 +304,8 @@ Deployment:
     usefulness: 2
     level: 3
     implementation:
-    - Docker
+    - name: Docker
+      tags: []
     dependsOn:
     - Same artifact for environments
     samm: EG1-B
@@ -300,8 +321,9 @@ Deployment:
     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 whitelist a
-      signing key.
+    - name: Kubernetes Admission Controller can whitelist registries and/or whitelist
+        a signing key.
+      tags: []
     difficultyOfImplementation:
       knowledge: 1
       time: 1
@@ -385,8 +407,11 @@ Patch Management:
     - 12.6.1
     - 14.2.5
     implementation:
-    - <a href="https://dependabot.com/">dependabot</a>
-    - Jenkins
+    - name: dependabot
+      tags: []
+      url: https://dependabot.com/
+    - name: Jenkins
+      tags: []
   Usage of a maximum lifetime for images:
     risk:
     - Vulnerabilities in images of running containers stay for too long and might
@@ -420,16 +445,19 @@ Patch Management:
     iso27001-2017:
     - 12.6.1
     implementation:
-    - Sample concept:<br/>(1) each container has a set lifetime and is killed / replaced
-      with a new container multiple times a day where you have some form of a graceful
-      replacement to ensure no (short) service outage will occur to the end users.<br/>(2)
-      twice a day a rebuild of images is done. The rebuilds are put into a automated
-      testing pipeline. If the testing has no blocking issues the new images will
-      be released for deployment during the next "restart" of a container. What has
-      to be done, is to ensure the new containers are deployed in some canary deployment
-      manner, this will ensure that if (and only if) something buggy has been introduced
-      which breaks functionality the canary deployment will make sure the "older version"
-      is being used and not the buggy newer one.
+    - name: "Sample concept:  \n(1"
+      tags: []
+      description: "Sample concept:  \n(1) each container has a set lifetime and is\
+        \ killed / replaced with a new container multiple times a day where you have\
+        \ some form of a graceful replacement to ensure no (short) service outage\
+        \ will occur to the end users.  \n(2) twice a day a rebuild of images is done.\
+        \ The rebuilds are put into a automated testing pipeline. If the testing has\
+        \ no blocking issues the new images will be released for deployment during\
+        \ the next \"restart\" of a container. What has to be done, is to ensure the\
+        \ new containers are deployed in some canary deployment manner, this will\
+        \ ensure that if (and only if) something buggy has been introduced which breaks\
+        \ functionality the canary deployment will make sure the \"older version\"\
+        \ is being used and not the buggy newer one."
   Reduction of the attack surface:
     risk:
     - Components, dependencies, files or file access rights might have vulnerabilities,
@@ -447,5 +475,9 @@ Patch Management:
     - hardening is missing in ISO 27001
     - 14.2.1
     implementation:
-    - <a href="https://github.com/GoogleContainerTools/distroless">Distroless</a>
-    - <a href="https://getfedora.org/coreos?stream=stable">Fedora CoreOS</a>
+    - name: Distroless
+      tags: []
+      url: https://github.com/GoogleContainerTools/distroless
+    - name: Fedora CoreOS
+      tags: []
+      url: https://getfedora.org/coreos

data-new/CultureAndOrganization/Design.yaml

@@ -62,7 +62,9 @@ Design:
     usefulness: 3
     level: 1
     implementation:
-    - <a href="https://github.com/Toreon/threat-model-playbook">Threat modeling Playbook</a>
+    - name: Threat modeling Playbook
+      tags: []
+      url: https://github.com/Toreon/threat-model-playbook
     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.
@@ -126,9 +128,12 @@ Design:
     - 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>
+    - name: "[Don't Forget EVIL U"
+      tags: []
+      url: https://www.owasp.org/index.php/Agile_Software_Development
+      description: "[Don't Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories)\
+        \ and [Practical Security Stories and Security Tasks for Agile Development\
+        \ Environments](http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)"
   Creation of simple abuse stories:
     risk:
     - User stories mostly don't consider security implications. Security flaws are
@@ -148,9 +153,12 @@ Design:
     - 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>
+    - name: "[Don't Forget EVIL U"
+      tags: []
+      url: https://www.owasp.org/index.php/Agile_Software_Development
+      description: "[Don't Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories)\
+        \ and [Practical Security Stories and Security Tasks for Agile Development\
+        \ Environments](http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)"
   Information security targets are communicated:
     risk:
     - Employees don't known their organizations security targets. Therefore security

data-new/CultureAndOrganization/Process.yaml

@@ -67,6 +67,8 @@ Process:
     - 12.5.1
     - 12.6.1
     implementation:
-    - 'Example: All docker images used by teams need to be based on standard images.'
+    - name: 'Example: All docker images used by teams need to be based on standard
+        images.'
+      tags: []
     comment: By preventing teams from trying out new components, innovation might
       be hampered

data-new/Implementation/ApplicationHardening.yaml

@@ -35,9 +35,12 @@ Application Hardening:
 
       Source: [OWASP Project Integration](https://raw.githubusercontent.com/OWASP/www-project-integration-standards/master/writeups/owasp_in_sdlc/index.md)
     implementation:
-    - <a href='https://owasp.org/www-project-application-security-verification-standard/'>OWASP
-      ASVS</a>
-    - <a href="https://github.com/OWASP/owasp-masvs">OWASP MASVS</a>
+    - name: OWASP ASVS
+      tags: []
+      url: https://owasp.org/www-project-application-security-verification-standard/
+    - name: OWASP MASVS
+      tags: []
+      url: https://github.com/OWASP/owasp-masvs
     samm2: software-requirements|A|1
     iso27001-2017:
     - hardening is not explicitly covered by ISO 27001 - too specific
@@ -59,9 +62,12 @@ Application Hardening:
     usefulness: 4
     level: 2
     implementation:
-    - <a href='https://owasp.org/www-project-application-security-verification-standard/'>OWASP
-      ASVS</a>
-    - <a href="https://github.com/OWASP/owasp-masvs">OWASP MASVS</a>
+    - name: OWASP ASVS
+      tags: []
+      url: https://owasp.org/www-project-application-security-verification-standard/
+    - name: OWASP MASVS
+      tags: []
+      url: https://github.com/OWASP/owasp-masvs
     samm2: software-requirements|A|2
     iso27001-2017:
     - hardening is not explicitly covered by ISO 27001 - too specific
@@ -84,9 +90,12 @@ Application Hardening:
     usefulness: 4
     level: 3
     implementation:
-    - <a href='https://owasp.org/www-project-application-security-verification-standard/'>OWASP
-      ASVS</a>
-    - <a href="https://github.com/OWASP/owasp-masvs">OWASP MASVS</a>
+    - name: OWASP ASVS
+      tags: []
+      url: https://owasp.org/www-project-application-security-verification-standard/
+    - name: OWASP MASVS
+      tags: []
+      url: https://github.com/OWASP/owasp-masvs
     samm2: software-requirements|A|3
     iso27001-2017:
     - hardening is not explicitly covered by ISO 27001 - too specific
@@ -109,9 +118,12 @@ Application Hardening:
     usefulness: 4
     level: 4
     implementation:
-    - <a href='https://owasp.org/www-project-application-security-verification-standard/'>OWASP
-      ASVS</a>
-    - <a href="https://github.com/OWASP/owasp-masvs">OWASP MASVS</a>
+    - name: OWASP ASVS
+      tags: []
+      url: https://owasp.org/www-project-application-security-verification-standard/
+    - name: OWASP MASVS
+      tags: []
+      url: https://github.com/OWASP/owasp-masvs
     samm2: software-requirements|A|3
     iso27001-2017:
     - hardening is not explicitly covered by ISO 27001 - too specific

data-new/InformationGathering/Logging.yaml

@@ -33,10 +33,14 @@ Logging:
     usefulness: 1
     level: 1
     implementation:
-    - rsyslog
-    - logstash
-    - fluentd
-    - bash
+    - name: rsyslog
+      tags: []
+    - name: logstash
+      tags: []
+    - name: fluentd
+      tags: []
+    - name: bash
+      tags: []
     samm2: o-incident-management|A|1
     iso27001-2017:
     - not explicitly covered by ISO 27001 - too specific
@@ -56,10 +60,14 @@ Logging:
     dependsOn:
     - PII logging concept
     implementation:
-    - rsyslog
-    - logstash
-    - fluentd
-    - bash
+    - name: rsyslog
+      tags: []
+    - name: logstash
+      tags: []
+    - name: fluentd
+      tags: []
+    - name: bash
+      tags: []
     samm2: o-incident-management|A|1
     iso27001-2017:
     - 12.4.1
@@ -77,8 +85,10 @@ Logging:
     usefulness: 2
     level: 1
     implementation:
-    - rsyslog
-    - ' Logstash'
+    - name: rsyslog
+      tags: []
+    - name: Logstash
+      tags: []
     samm2: o-incident-management|A|1
     iso27001-2017:
     - not explicitly covered by ISO 27001 - too specific
@@ -120,7 +130,8 @@ Logging:
     - Centralized system logging
     - Centralized application logging
     implementation:
-    - ELK-Stack
+    - name: ELK-Stack
+      tags: []
     samm2: o-incident-management|A|1
     iso27001-2017:
     - not explicitly covered by ISO 27001 - too specific