Merge pull request #79 from ioggstream/ioggstream-76

Fix: #76. Reformat yaml files using update_schema.py

Author: wurstbrot

data-new/BuildAndDeployment/Sub-Dimensions.yaml

@@ -1,7 +1,7 @@
----
 Design:
   Conduction of advanced threat modeling:
-    risk: Inadequate identification of business and technical risks.
+    risk:
+    - Inadequate identification of business and technical risks.
     measure: Threat modeling is performed by using reviewing user stories and producing
       security driven data flow diagrams.
     difficultyOfImplementation:
@@ -29,9 +29,11 @@ Design:
     - may be part of risk assessment
     - 8.2.1
     - 14.2.1
+    implementation: []
   Conduction of simple threat modeling on business level:
-    risk: Business related threats are discovered too late in the development and
-      deployment process.
+    risk:
+    - Business related threats are discovered too late in the development and deployment
+      process.
     measure: Threat modeling of business functionality is performed during the product
       backlog creation to facilitate early detection of security defects.
     difficultyOfImplementation:
@@ -46,9 +48,11 @@ Design:
     - may be part of risk assessment
     - 8.2.1
     - 14.2.1
+    implementation: []
   Conduction of simple threat modeling on technical level:
-    risk: Technical related threats are discovered too late in the development and
-      deployment process.
+    risk:
+    - Technical related threats are discovered too late in the development and deployment
+      process.
     measure: Threat modeling of technical features is performed during the product
       sprint planning.
     difficultyOfImplementation:
@@ -101,7 +105,8 @@ Design:
     - 8.2.1
     - 14.2.1
   Creation of advanced abuse stories:
-    risk: Simple user stories are not going deep enough. Relevant security considerations
+    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 modeling activities.
@@ -120,12 +125,14 @@ Design:
     - 6.1.5
     - 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
+    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>
   Creation of simple abuse stories:
-    risk: User stories mostly don't consider security implications. Security flaws
-      are discovered too late in the development and deployment process.
+    risk:
+    - User stories mostly don't consider security implications. Security flaws are
+      discovered too late in the development and deployment process.
     measure: Abuse stories are created during the creation of user stories.
     difficultyOfImplementation:
       knowledge: 2
@@ -140,11 +147,13 @@ Design:
     - 6.1.5
     - 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
+    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 organizations 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
@@ -159,4 +168,4 @@ Design:
     iso27001-2017:
     - 5.1.1
     - 7.2.1
-...
+    implementation: []

data-new/CultureAndOrganization/Design.yaml

@@ -1,9 +1,9 @@
----
 Education and Guidance:
   Ad-Hoc Security trainings for software developers:
-    risk: Understanding security is hard and personnel needs to be trained on it.
-      Otherwise, flaws like an SQL Injection might be introduced into the software
-      which might get exploited.
+    risk:
+    - Understanding security is hard and personnel needs to be trained on it. Otherwise,
+      flaws like an SQL Injection might be introduced into the software which might
+      get exploited.
     measure: Provide security awareness training for all personnel involved in software
       development Ad-Hoc.
     difficultyOfImplementation:
@@ -21,7 +21,8 @@ Education and Guidance:
     iso27001-2017:
     - 7.2.2
   Regular security training for all:
-    risk: Understanding security is hard.
+    risk:
+    - Understanding security is hard.
     measure: Provide security awareness training for all personnel involved in software
       development on a regular basis like twice in a year for 1-3 days.
     difficultyOfImplementation:
@@ -39,7 +40,8 @@ Education and Guidance:
       Shop</a> on a "hacking Friday"
     - https://cheatsheetseries.owasp.org/
   Security consulting on request:
-    risk: Not asking a security expert when questions regarding security appear might
+    risk:
+    - Not asking a security expert when questions regarding security appear might
       lead to flaws.
     measure: Security consulting to teams is given on request. The security consultants
       can be internal or external.
@@ -55,8 +57,10 @@ Education and Guidance:
     - 6.1.1
     - 6.1.4
     - 6.1.5
+    implementation: []
   Regular security training of security champions:
-    risk: Understanding security is hard, even for security champions.
+    risk:
+    - Understanding security is hard, even for security champions.
     measure: Regular security training of security champions.
     evidence: |
       - Process Documentation: TODO
@@ -71,8 +75,10 @@ Education and Guidance:
     iso27001-2017:
     - security champions are missing in ISO 27001
     - 7.2.2
+    implementation: []
   Regular security training for everyone:
-    risk: Understanding security is hard, for internal as well as external employees.
+    risk:
+    - Understanding security is hard, for internal as well as external employees.
     measure: Regular security training for everyone.
     difficultyOfImplementation:
       knowledge: 3
@@ -83,12 +89,14 @@ Education and Guidance:
     samm: EG2-B
     iso27001-2017:
     - 7.2.2
-    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.
+    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:
-    risk: No one feels directly responsible for security and the security champion
-      does not have enough time to allocate to each team.
+    risk:
+    - No one feels directly responsible for security and the security champion does
+      not have enough time to allocate to each team.
     measure: Each team defines an individual to be responsible for security. These
       individuals are often referred to as 'security champions'
     difficultyOfImplementation:
@@ -102,10 +110,11 @@ Education and Guidance:
     - security champions are missing in ISO 27001 most likely
     - 7.2.1
     - 7.2.2
-    implementation: 
+    implementation:
     - OWASP Security Champions Playbook: https://github.com/c0rdis/security-champions-playbook
   Security-Lessoned-Learned:
-    risk: After an incident, a similar incident might reoccur.
+    risk:
+    - After an incident, a similar incident might reoccur.
     measure: Running a 'lessons learned' session after an incident helps drive continuous
       improvement. Regular meetings with security champions are a good place to share
       and discuss lessons learned.
@@ -118,9 +127,11 @@ Education and Guidance:
     samm: IM-3, ST-3, SR2-B
     iso27001-2017:
     - 16.1.6
+    implementation: []
   Conduction of collaborative security checks with developers and system administrators:
-    risk: Security checks by external companies do not increase the understanding
-      of an application/system for internal employees.
+    risk:
+    - Security checks by external companies do not increase the understanding of an
+      application/system for internal employees.
     measure: Periodically security reviews of source code (SCA), in which security
       SME, developers and operations are involved, are effective at increasing the
       robustness of software and the security knowledge of the teams involved.
@@ -136,8 +147,10 @@ Education and Guidance:
     - 7.2.2
     - 12.6.1
     - 12.7.1
+    implementation: []
   Conduction of collaborative team security checks:
-    risk: Development teams limited insight over security practices.
+    risk:
+    - Development teams limited insight over security practices.
     measure: Mutual security testing the security of other teams project enhances
       security awareness and knowledge.
     difficultyOfImplementation:
@@ -150,8 +163,10 @@ Education and Guidance:
     iso27001-2017:
     - Mutual security testing is not explicitly required in ISO 27001 may be
     - 7.2.2
+    implementation: []
   Conduction of build-it, break-it, fix-it contests:
-    risk: Understanding security is hard, even for security champions and the conduction
+    risk:
+    - Understanding security is hard, even for security champions and the conduction
       of security training often focuses on breaking a component instead of building
       a component secure.
     measure: The build-it, break-it, fix-it contest allows to train people with security
@@ -165,9 +180,11 @@ Education and Guidance:
     level: 3
     iso27001-2017:
     - 7.2.2
-    implementation: https://builditbreakit.org/
+    implementation:
+    - https://builditbreakit.org/
   Conduction of war games:
-    risk: Understanding incident response plans during an incident is hard and ineffective.
+    risk:
+    - Understanding incident response plans during an incident is hard and ineffective.
     measure: War Games like activities help train for incidents. Security SMEs create
       attack scenarios in a testing environment enabling the trainees to learn how
       to react in case of an incident.
@@ -180,10 +197,12 @@ Education and Guidance:
     iso27001-2017:
     - ware games are not explicitly required in ISO 27001 may be
     - 7.2.2
-    - "16.1"
+    - '16.1'
     - 16.1.5
+    implementation: []
   Reward of good communication:
-    risk: Employees are not getting excited about security.
+    risk:
+    - Employees are not getting excited about security.
     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'.
@@ -203,7 +222,8 @@ Education and Guidance:
       Project</a>
     - https://owaspsamm.org/presentations/OWASP_Top_10_Maturity_Categories_for_Security_Champions.pptx
   Aligning security in teams:
-    risk: The concept of Security Champions might suggest that only he/she is responsible
+    risk:
+    - The concept of Security Champions might suggest that only he/she is responsible
       for security. However, everyone in the project team should be responsible for
       security.
     measure: By aligning security SME with project teams, a higher security standard
@@ -212,11 +232,10 @@ Education and Guidance:
       knowledge: 4
       time: 5
       resources: 1
-    implementation: Security SME are involved in discussion for requirements analysis,
-      software design and sprint planning to provide guidance and suggestions.
+    implementation:
+    - Security SME are involved in discussion for requirements analysis, software design and sprint planning to provide guidance and suggestions.
     usefulness: 5
     level: 4
     samm: EG2-B
     iso27001-2017:
     - 7.1.1
-...

data-new/CultureAndOrganization/EducationAndGuidance.yaml

@@ -1,8 +1,8 @@
----
 Process:
   Definition of simple BCDR practices for critical components:
-    risk: In case of an emergency, like a power outage, DR actions to perform are
-      not clear. This leads to reaction and remediation delays.
+    risk:
+    - In case of an emergency, like a power outage, DR actions to perform are not
+      clear. This leads to reaction and remediation delays.
     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
@@ -16,9 +16,10 @@ Process:
     level: 1
     iso27001-2017:
     - 17.1.1
+    implementation: []
   Definition of a change management process:
-    risk: The impact of a change is not controlled because these are not recorded
-      or documented.
+    risk:
+    - The impact of a change is not controlled because these are not recorded or documented.
     measure: Each change of a system is automatically recorded and adequately logged.
     difficultyOfImplementation:
       knowledge: 4
@@ -30,8 +31,10 @@ Process:
     - 14.2.2
     - 12.1.2
     - 12.4.1
+    implementation: []
   Approval by reviewing any new version:
-    risk: An individual might forget to implement security measures to protect source
+    risk:
+    - An individual might forget to implement security measures to protect source
       code or infrastructure components.
     measure: On each new version (e.g. Pull Request) of source code or infrastructure
       components a security peer review of the changes is performed (two eyes principle)
@@ -47,8 +50,10 @@ Process:
     - peer review - four eyes principle is not explicitly required by ISO 27001
     - 6.1.2
     - 14.2.1
+    implementation: []
   Prevention of unauthorized installation:
-    risk: Unapproved components are used.
+    risk:
+    - Unapproved components are used.
     measure: Components must be whitelisted. Regular scans on the docker infrastructure
       (e.g. cluster) need to be performed, to verify that only standardized base images
       are used.
@@ -61,8 +66,7 @@ Process:
     iso27001-2017:
     - 12.5.1
     - 12.6.1
-    implementation: 'Example: All docker images used by teams need to be based on
-      standard images.'
+    implementation:
+    - 'Example: All docker images used by teams need to be based on standard images.'
     comment: By preventing teams from trying out new components, innovation might
       be hampered
-...

data-new/CultureAndOrganization/Process.yaml

@@ -1,6 +1,5 @@
----
 _meta:
-  label: "Culture and Organization"
-  icon: "Culture and Org.png"
+  label: Culture and Organization
+  icon: Culture and Org.png
   description: |-
-    A markdown description of this dimension.
+    A markdown description of this dimension.

data-new/CultureAndOrganization/_meta.yaml

@@ -1,7 +1,7 @@
----
 Application Hardening:
   Application Hardening Level 1:
-    risk: Using an insecure application might lead to a compromised application. This
+    risk:
+    - Using an insecure application might lead to a compromised application. This
       might lead to total data theft or data modification.
     measure: |
       Following frameworks like the
@@ -43,7 +43,8 @@ Application Hardening:
     - hardening is not explicitly covered by ISO 27001 - too specific
     - 13.1.3
   App. Hardening Level 2:
-    risk: Using an insecure application might lead to a compromised application. This
+    risk:
+    - Using an insecure application might lead to a compromised application. This
       might lead to total data theft or data modification.
     measure: |
       Following frameworks like the
@@ -66,7 +67,8 @@ Application Hardening:
     - hardening is not explicitly covered by ISO 27001 - too specific
     - 13.1.3
   App. Hardening Level 3:
-    risk: Using an insecure application might lead to a compromised application. This
+    risk:
+    - Using an insecure application might lead to a compromised application. This
       might lead to total data theft or data modification.
     measure: |
       Following frameworks like the
@@ -90,7 +92,8 @@ Application Hardening:
     - hardening is not explicitly covered by ISO 27001 - too specific
     - 13.1.3
   Full Coverage of App. Hardening Level 3:
-    risk: Using an insecure application might lead to a compromised application. This
+    risk:
+    - Using an insecure application might lead to a compromised application. This
       might lead to total data theft or data modification.
     measure: |
       Following frameworks like the
@@ -113,4 +116,3 @@ Application Hardening:
     iso27001-2017:
     - hardening is not explicitly covered by ISO 27001 - too specific
     - 13.1.3
-...