Review of level 1 activities

src/assets/YAML/default/BuildAndDeployment/Build.yaml

@@ -28,7 +28,7 @@ Build and Deployment:
       level: 2
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
       references:
         samm2:
           - I-SB-2-A
@@ -42,34 +42,36 @@ Build and Deployment:
     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.
+        A *build process* includes more than just compiling your source code. It also covers:
+        - Managing (third party) dependencies
+        - Environment configuration
+        - Running unit and integration tests
+        - Security scanning and compliance checks
+        - Artifact creation and storage
+        - Deployment preparation
 
-        This can be done with a Jenkinsfile, Maven, or similar tools.
+        Basing the build process on human memory may lead to inconsistencies and security misconfigurations.
+
+        A *defined build process* can automate these steps to ensure consistency, avoiding accidental omissions or misconfigurations. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process.
+
+        A simplified, but still a *defined build process*, may be a checklist of the steps to be performed.
       risk:
-        Performing builds without a defined process is error prone; for example,
-        as a result of incorrect security related configuration.
+        Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations.
       measure:
-        A well defined build process lowers the possibility of errors during
-        the build process.
+        Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
+      assessment: |
+        - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 3
         resources: 2
       usefulness: 4
-      level: 1
-      assessment: |
-        - Show your build pipeline and an exemplary job (build + test).
-        - Show that every team member has access.
-        - Show that failed jobs are fixed.
-
-        Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/)
       implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/maven
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
       references:
         samm2:
           - I-SB-1-A
@@ -142,7 +144,9 @@ Build and Deployment:
         resources: 3
       usefulness: 3
       level: 2
-      implementation: []
+      implementation: 
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/syft
       references:
         samm2:
           - I-SB-1-A

src/assets/YAML/default/BuildAndDeployment/Deployment.yaml

@@ -69,19 +69,21 @@ Build and Deployment:
       comments: ""
     Defined deployment process:
       uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a
+      description: |
+        A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms.
       risk: >-
-        Deployment of insecure or malfunctioning artifacts.
+        Deployment based human routines are error prone, and of insecure or malfunctioning artifacts.
       measure: >-
         Defining a deployment process ensures that there are
         established criteria in terms of functionalities,
         security, compliance, and performance,
         and that the artifacts meet them.
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 1
       usefulness: 4
-      level: 1
       dependsOn:
         - uuid:f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
       implementation:
@@ -96,6 +98,11 @@ Build and Deployment:
         iso27001-2022:
           - 5.37
           - 8.32
+      assessment: |
+        - Deployment process is documented and available to relevant staff
+        - All deployment steps are automated
+        - Rollback procedures are defined and tested [Keep??? Delete???]
+        - Provide audit logs or evidence of deployments
       isImplemented: false
       evidence: ""
       comments: ""
@@ -211,19 +218,24 @@ Build and Deployment:
         - sbom
     Inventory of production components:
       uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f
+      description: |
+        An inventory of production components is a complete, up-to-date list of all applications running in production. This enables effective vulnerability management, incident response, and compliance. Without it, organizations risk running unmaintained or unauthorized software.
       risk: |-
         An organization is unaware of components like applications in production. Not knowing existing applications in production leads to not assessing it.
       measure: |-
         A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production.
         In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track.
+      assessment: |
+        - Inventory of all production applications with application name, owner, and date of last review
+        - Inventory is accessible to development, security and operations teams
       dependsOn:
         - Defined deployment process
+      level: 1
       difficultyOfImplementation:
         knowledge: 1
         time: 1
         resources: 1
       usefulness: 4
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack

src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml

@@ -4,16 +4,23 @@ Build and Deployment:
   Patch Management:
     A patch policy is defined:
       uuid: 99415139-6b50-441b-89e1-0aa59accd43d
-      risk: Vulnerabilities in running artifacts stay for long and might get exploited.
+      description: |
+        A patch policy defines how and when software components, images, and dependencies are updated. A patch policy ensures that all these artifacts are regularly reviewed and updated, reducing the window of exposure to known threats. The policy should specify the frequency, responsibilities, and documentation requirements for patching.
+      risk: Vulnerabilities in running artifacts may persist for a long time and might be exploited.
       measure:
-        A patch policy for all artifacts (e.g. in images) is defined. How often
+        Define a patch policy for all artifacts (e.g. in images) is defined. How often
         is an image rebuilt?
+      assessment: |
+        - Patch policy is documented and accessible to relevant staff.
+        - The policy defines patch frequency and responsible roles.
+        - Patch actions and exceptions are logged and reviewed.
+        - Evidence of regular patching and policy review is available.
+      level: 1
       difficultyOfImplementation:
         knowledge: 3
         time: 1
         resources: 2
       usefulness: 4
-      level: 1
       implementation: []
       references:
         samm2:
@@ -33,23 +40,27 @@ Build and Deployment:
         - patching
     Automated PRs for patches:
       uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488
-      risk:
-        Components with known (or unknown) vulnerabilities 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
-
+      description: |
+        Automated PRs for patches ensure that updates for outdated or vulnerable dependencies are created and proposed without manual intervention. Tools continuously monitor for new versions or security advisories and immediately generate pull requests to update affected components in code, container images, or infrastructure. This process ensures that available patches are quickly visible to developers and can be reviewed and merged with minimal delay, reducing the risk window for known vulnerabilities.
+      risk: |
+        Components with known vulnerabilities might persist for a long time and be exploited, even when a patch is available.
+      measure: |
+        Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes:
         * Applications
-        * Virtualized operating system components (e.g. container images)
-        * Operating Systems
-        * Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform)
+        * Virtualized operating system components (e.g., container images)
+        * Operating systems
+        * Infrastructure as Code/GitOps (e.g., ArgoCD based on a git repository or Terraform)
+      assessment: |
+        - Automated PR tooling is enabled for all relevant repositories.
+        - PRs are created automatically for outdated or vulnerable dependencies.
+        - PRs are reviewed and merged according to the defined patch policy.
+        - Evidence of automated PRs and patching activity is available.
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 4
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependabot
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins

src/assets/YAML/default/CultureAndOrganization/Design.yaml

@@ -87,25 +87,6 @@ Culture and Organization:
       comments: ""
     Conduction of simple threat modeling on technical level:
       uuid: 47419324-e263-415b-815d-e7161b6b905e
-      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:
-        knowledge: 2
-        time: 3
-        resources: 1
-      usefulness: 3
-      level: 1
-      implementation:
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
       description: |
         # OWASP SAMM Description
         Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment.
@@ -149,6 +130,26 @@ Culture and Organization:
         GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes.
 
         Source: OWASP Project Integration Project
+      risk:
+        Technical related threats are discovered too late in the development and deployment process.
+      measure: |
+        Perform threat modeling of technical features during product sprint planning using simple checklists and diagrams. Document identified threats and mitigations for new or changed functionality.
+      assessment: |
+        - Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations.
+        - Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review.
+      level: 1
+      difficultyOfImplementation:
+        knowledge: 2
+        time: 3
+        resources: 1
+      usefulness: 3
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
       references:
         samm2:
           - D-TA-2-B

src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml

@@ -4,19 +4,22 @@ Culture and Organization:
   Education and Guidance:
     Ad-Hoc Security trainings for software developers:
       uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298
-      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.
+      description: |
+        Ad-hoc security training provides basic awareness of software security risks and best practices to developers and other personnel involved in software development. These trainings are delivered as needed, without a fixed schedule, to address immediate knowledge gaps or respond to emerging threats.
+      risk: |
+        Without any security training, personnel may lack awareness of common software vulnerabilities (such as SQL Injection and vulnerable dependencies), increasing the risk of introducing exploitable flaws into applications.
+      measure: |
+        Provide security awareness training for all personnel involved in software development on an ad-hoc basis, ensuring that relevant topics are covered when new risks or needs are identified.
+      assessment: |
+        - Conduct security training for developers and relevant personnel
+        - Training materials are available
+        - Attendance records are available
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 1
         resources: 1
       usefulness: 3
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-juice-shop
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series
@@ -407,18 +410,20 @@ Culture and Organization:
       comments: ""
     Security consulting on request:
       uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0
-      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.
+      level: 1
+      description: |
+        Security consulting on request allows teams to seek expert advice on security-related questions or challenges as they arise. This support can be provided by internal or external security consultants and helps address specific concerns during software development.
+      risk: |
+        If teams do not consult security experts when questions arise, security flaws may be introduced or remain undetected, increasing the risk of vulnerabilities in the software.
+      measure: |
+        Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development.
+      assessment: |
+        Records show that teams have access to security consulting services and have used them when needed. Documentation of consultations and resulting actions is available for review.
       difficultyOfImplementation:
         knowledge: 3
         time: 1
         resources: 1
       usefulness: 3
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series
       references:

src/assets/YAML/default/CultureAndOrganization/Process.yaml

@@ -58,24 +58,23 @@ 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:
+      description: |
+        Business Continuity and Disaster Recovery (BCDR) is a plan and a process that enable an organization to quickly restore normal operations after a disruptive event, such as a cyberattack or natural disaster.
+      risk: |
         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 by the people involved in the recovery.
+      measure: |
+        Develop, document, and communicate a BCDR plan for all critical components. The plan must define roles and responsibilities, Service Level Agreements (SLAs), Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs), and failover procedures. Ensure all relevant personnel are trained and the plan is reviewed and updated regularly.
+      assessment: |
+        - There is a documented BCDR plan covering all critical components of the application(s).
+        - The plan clearly defines responsibilities, SLAs, RPOs, RTOs, and failover steps. 
+        - Relevant staff are aware of the plan, and evidence of regular review and testing is available.
+      level: 1
       difficultyOfImplementation:
         knowledge: 4
         time: 3
         resources: 2
       usefulness: 4
-      level: 1
       implementation: []
       references:
         samm2: []

src/assets/YAML/default/Implementation/InfrastructureHardening.yaml

@@ -366,6 +366,8 @@ Implementation:
       uuid: 82e499d1-f463-4a4b-be90-68812a874af6
       risk: Attackers a gaining access to internal systems and application interfaces
       measure: All internal systems are using simple authentication
+      assessment: |
+        - Demonstrate that every team member has appropriate access (least privilege).        
       difficultyOfImplementation:
         knowledge: 3
         time: 3