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
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:
149
130
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.
150
131
151
132
Source: OWASP Project Integration Project
133
+
risk:
134
+
Technical related threats are discovered too late in the development and deployment process.
135
+
measure: |
136
+
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.
137
+
assessment: |
138
+
- Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations.
139
+
- Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review.
Copy file name to clipboardExpand all lines: src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
+21-15Lines changed: 21 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -4,19 +4,23 @@ Culture and Organization:
4
4
Education and Guidance:
5
5
Ad-Hoc Security trainings for software developers:
6
6
uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298
7
-
risk:
8
-
Understanding security is hard and personnel needs to be trained on it.
9
-
Otherwise, flaws like an SQL Injection might be introduced into the software
10
-
which might get exploited.
11
-
measure:
12
-
Provide security awareness training for all personnel involved in software
13
-
development Ad-Hoc.
7
+
description: |
8
+
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.
9
+
risk: |
10
+
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.
11
+
measure: |
12
+
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.
13
+
assessment: |
14
+
- Conduct security training for developers and relevant personnel
15
+
- Participants can identify common software security risks addressed in the training
Not asking a security expert when questions regarding security appear
412
-
might lead to flaws.
413
-
measure:
414
-
Security consulting to teams is given on request. The security consultants
415
-
can be internal or external.
414
+
level: 1
415
+
description: |
416
+
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.
417
+
risk: |
418
+
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.
419
+
measure: |
420
+
Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development.
421
+
assessment: |
422
+
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.
Copy file name to clipboardExpand all lines: src/assets/YAML/default/CultureAndOrganization/Process.yaml
+10-11Lines changed: 10 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -58,24 +58,23 @@ Culture and Organization:
58
58
comments: ""
59
59
Definition of simple BCDR practices for critical components:
60
60
uuid: c72da779-86cc-45b1-a339-190ce5093171
61
-
description:
62
-
A _Business Continuity and Disaster Recovery_ (BCDR) is a plan and a process
63
-
that helps a business to return to normal operations if a disaster occurs.
64
-
risk:
61
+
description: |
62
+
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.
63
+
risk: |
65
64
If the disaster recovery actions are not clear, you risk slow reaction and remediation delays.
66
65
This applies to cyber attacks as well as natural emergencies, such as a power outage.
67
-
measure:
68
-
By understanding and documenting a business continuity and disaster
69
-
recovery (BCDR) plan, the overall availability of systems and applications
70
-
is increased. Success factors like responsibilities, Service Level Agreements,
71
-
Recovery Point Objectives, Recovery Time Objectives or Failover must be fully
72
-
documented and understood by the people involved in the recovery.
66
+
measure: |
67
+
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.
68
+
assessment: |
69
+
- The organization has a documented BCDR plan covering all critical components.
70
+
- The plan clearly defines responsibilities, SLAs, RPOs, RTOs, and failover steps.
71
+
- Relevant staff are aware of the plan, and evidence of regular review and testing is available.
0 commit comments