You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: src/assets/YAML/default/CultureAndOrganization/Process.yaml
+39-3
Original file line number
Diff line number
Diff line change
@@ -80,6 +80,42 @@ Culture and Organization:
80
80
- 17.1.1
81
81
iso27001-2022:
82
82
- 5.29
83
-
isImplemented: false
84
-
evidence: ""
85
-
comments: ""
83
+
Determining the protection requirement:
84
+
uuid: 123e4567-e89b-12d3-a456-426614174000
85
+
risk: |-
86
+
Not defining the protection requirement of applications can lead to wrong prioritization, delayed remediation of
87
+
critical security issues, increasing the risk of exploitation and potential damage to the organization.
88
+
measure: |-
89
+
Defining the SLA to respond to findings depending on protection requirement and the corresponding handling of vulnerabilities per severity for components like applications are aligned to SLAs.
90
+
This is performed for the hole organization and doesn't need to be broken down (yet) on team/product/application.
91
+
At least quarterly.
92
+
description: |-
93
+
The protection requirements for an application should consider:
94
+
- Data criticality
95
+
- Application accessibility (internal vs. external)
Copy file name to clipboardexpand all lines: src/assets/YAML/default/InformationGathering/TestKPI.yaml
+37-30
Original file line number
Diff line number
Diff line change
@@ -33,24 +33,33 @@ Information Gathering:
33
33
- vulnerability-mgmt
34
34
- metrics
35
35
- vmm-measurement
36
-
Patching mean time to resolution via PR:
37
-
uuid: 86d490b9-d798-4a5b-a011-ab9688014c46
36
+
Number of vulnerabilities/severity/layer:
37
+
uuid: 0ec92899-a5cb-4649-984b-2fb1d6c784ad
38
38
risk: |-
39
-
Without measuring Mean Time to Resolution (MTTR) related to patching, it is challenging to identify delays in the patching process. Unaddressed vulnerabilities can be exploited by attackers, leading to potential security breaches and data loss.
39
+
Failing to convey the number of vulnerabilities by severity and layer (app/infra) might undermine the effectiveness of product teams. This might lead to ignorance of findings.
40
40
measure: |-
41
-
Measurement and communication of patching Mean Time to Resolution (MTTR) in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis.
42
-
This includes the measurement of the existence of a properly configured automated pull request (PR) tool (e.g., Dependabot or Renovate) in a repository.
43
-
In addition, the measurement of the time from opening an automated PR to merging it.
41
+
Measurement and communication of vulnerabilities per severity for components like applications and split it depending on the layer (e.g. app/infra). At least quarterly.
42
+
description: |-
43
+
Communication can be performed in a simple way, e.g. text based during the build process.
44
+
This activity depends on at least one security testing implementation.
45
+
Layers to consider (SCA):
46
+
- Cloud provider (if insights are possible)
47
+
- Runtimes, e.g. Kubernetes nodes
48
+
- Base images and container images
49
+
- Application
44
50
45
-
Average time to patch is visualized per component/project/team.
51
+
Layers to consider SAST/DAST:
52
+
- Cloud provider
53
+
- Runtime, e.g. Kubernetes
54
+
- Base images and container images
55
+
- Application
46
56
difficultyOfImplementation:
47
-
knowledge: 1
48
-
time: 1
57
+
knowledge: 2
58
+
time: 2
49
59
resources: 2
50
60
usefulness: 3
51
61
level: 2
52
-
dependsOn:
53
-
- uuid:8ae0b92c-10e0-4602-ba22-7524d6aed488 #Automated PRs for patches
62
+
dependsOn: []
54
63
implementation: []
55
64
references:
56
65
samm2:
@@ -61,30 +70,28 @@ Information Gathering:
61
70
- 5.13
62
71
- 5.10
63
72
tags:
64
-
- patching
73
+
- vulnerability-mgmt
65
74
- metrics
66
-
- vmm-measurements
67
-
SLA per criticality: # is this the definition of SLAs or the measurement?
68
-
uuid: 123e4567-e89b-12d3-a456-426614174000
75
+
- vmm-measurement
76
+
Patching mean time to resolution via PR:
77
+
uuid: 86d490b9-d798-4a5b-a011-ab9688014c46
69
78
risk: |-
70
-
Not communicating how many applications are adhering to SLAs based on the criticality of vulnerabilities can lead to delayed remediation of
71
-
critical security issues, increasing the risk of exploitation and potential damage to the organization.
79
+
Without measuring Mean Time to Resolution (MTTR) related to patching, it is challenging to identify delays in the patching process. Unaddressed vulnerabilities can be exploited by attackers, leading to potential security breaches and data loss.
72
80
measure: |-
73
-
Measurement and communication of how many of the vulnerabilities handling per severity for components like applications are aligned to SLAs.
74
-
This is performed for the hole organization and doesn't need to be broken down (yet) on team/product/application.
75
-
At least quarterly.
81
+
Measurement and communication of patching Mean Time to Resolution (MTTR) in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis.
82
+
This includes the measurement of the existence of a properly configured automated pull request (PR) tool (e.g., Dependabot or Renovate) in a repository.
83
+
In addition, the measurement of the time from opening an automated PR to merging it.
84
+
85
+
Average time to patch is visualized per component/project/team.
Copy file name to clipboardexpand all lines: src/assets/YAML/default/TestAndVerification/Consolidation.yaml
+39
Original file line number
Diff line number
Diff line change
@@ -379,3 +379,42 @@ Test and Verification:
379
379
tags:
380
380
- vulnerability-mgmt
381
381
- vmm-measurements
382
+
Treatment of defects per protection requirement:
383
+
uuid: 123e4567-e89b-12d3-a456-426614174000
384
+
risk: |-
385
+
Not defining the protection requirement of applications can lead to wrong prioritization, delayed remediation of
386
+
critical security issues, increasing the risk of exploitation and potential damage to the organization.
387
+
measure: |-
388
+
Defining the protection requirement and the corresponding handling of vulnerabilities per severity for components like applications are aligned to SLAs.
389
+
This is performed for the hole organization and doesn't need to be broken down (yet) on team/product/application.
390
+
At least quarterly.
391
+
description: |-
392
+
The protection requirements for an application should consider:
393
+
- Data criticality
394
+
- Application accessibility (internal vs. external)
0 commit comments