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
- Application and system components like Open Source libraies or images can have implementation flaws or deployment flaws.
272
+
- Developers or operations might start random images in the production cluster
273
+
which have malicious code or known vulnerabilities.
274
+
measure:
275
+
- Each components source is evaluated to be trusted. For example the source, number of developers included, email configuration used by maintainers to prevent maintainer account theft, typo-squatting, ...
276
+
- Create image assessment criteria, perform an evaluation of images and create a whitelist of artifacts/container images/virtual machine images.
- hardening is not explicitly covered by ISO 27001 - too specific
27
-
- 13.1.3
28
-
isImplemented: false
29
-
evidence: ""
30
-
comments: ""
31
-
App. Hardening Level 3:
4
+
App. Hardening Level 1 (50%):
32
5
risk: Using an insecure application might lead to a compromised application.
33
6
This might lead to total data theft or data modification.
34
7
measure: |
35
8
Following frameworks like the
36
-
<ul>
37
-
<li>OWASP Application Security Verification Standard Level 3</li>
38
-
<li>OWASP Mobile Application Security Verification Standard Maturity Requirements</li>
39
-
</ul>
40
-
and gain around 75% coverage of both.
9
+
* OWASP Application Security Verification Standard Level 1
10
+
* OWASP Mobile Application Security Verification Standard
11
+
12
+
in all applications provides a good baseline. Implement 50% of the recommendations.
41
13
difficultyOfImplementation:
42
-
knowledge: 4
43
-
time: 4
44
-
resources: 2
45
-
usefulness: 4
46
-
level: 3
14
+
knowledge: 2
15
+
time: 2
16
+
resources: 1
17
+
usefulness: 3
18
+
level: 1
19
+
description: |
20
+
To tackle the security of code developed in-house, OWASP offers an extensive collection of [Cheatsheets](https://cheatsheetseries.owasp.org/) demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely.
The Requirements gathering process tries to answer the question: _"What is the system going to do?"_ At this stage, the [SAMM project](https://owaspsamm.org/model/) offers 3 distinct maturity levels covering both [in-house](https://owaspsamm.org/model/design/security-requirements/stream-a/) software development and [third party](https://owaspsamm.org/model/design/security-requirements/stream-b/) supplier security.
Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process.
30
+
31
+
These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations.
32
+
33
+
In case of internal development and if the organization maps Features to Epics, the [Security Knowledge Framework](https://securityknowledgeframework.org/) can be used to facilitate this process by leveraging its questionnaire function, shown below.
- hardening is not explicitly covered by ISO 27001 - too specific
55
-
- 13.1.3
44
+
- hardening is not explicitly covered by ISO 27001 - too specific
45
+
- 13.1.3
56
46
isImplemented: false
57
47
evidence: ""
58
48
comments: ""
59
-
Application Hardening Level 1:
49
+
App. Hardening Level 1:
60
50
risk: Using an insecure application might lead to a compromised application.
61
51
This might lead to total data theft or data modification.
62
52
measure: |
63
53
Following frameworks like the
64
-
<ul>
65
-
<li>OWASP Application Security Verification Standard Level 1</li>
66
-
<li>OWASP Mobile Application Security Verification Standard Level 1</li>
67
-
</ul>
68
-
69
-
in all applications provides a good baseline.
54
+
* OWASP Application Security Verification Standard Level 1
55
+
* OWASP Mobile Application Security Verification Standard
56
+
57
+
in all applications provides a good baseline. Implement 95%-100% of the recommendations.
70
58
difficultyOfImplementation:
71
-
knowledge: 4
72
-
time: 4
73
-
resources: 2
59
+
knowledge: 2
60
+
time: 2
61
+
resources: 1
74
62
usefulness: 4
75
-
level: 1
63
+
level: 2
64
+
dependsOn:
65
+
- App. Hardening Level 1 (50%)
76
66
description: |
77
67
To tackle the security of code developed in-house, OWASP offers an extensive collection of [Cheatsheets](https://cheatsheetseries.owasp.org/) demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely.
78
68
@@ -103,22 +93,80 @@ Implementation:
103
93
isImplemented: false
104
94
evidence: ""
105
95
comments: ""
106
-
Full Coverage of App. Hardening Level 3:
96
+
97
+
App. Hardening Level 2 (75%):
107
98
risk: Using an insecure application might lead to a compromised application.
108
99
This might lead to total data theft or data modification.
109
100
measure: |
110
101
Following frameworks like the
111
-
<ul>
112
-
<li>OWASP Application Security Verification Standard Level 3</li>
113
-
<li>OWASP Mobile Application Security Verification Standard Maturity Requirements</li>
114
-
</ul>
115
-
and gain around 95% coverage of both.
102
+
* OWASP Application Security Verification Standard Level 2
103
+
* OWASP Mobile Application Security Verification Standard Level 2
0 commit comments