Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: enhance descriptions #14

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

feat: enhance descriptions #14

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2bc6246
feat: enhance descriptions
wurstbrot Jan 3, 2025
c1ae63f
Suggested improvements, and spelling corrections
vbakke Jan 8, 2025
66f407d
Merge pull request #15 from vbakke/feat/descriptions-enhancement
wurstbrot Jan 9, 2025
dc8662c
change dependsOn to uuid:44f2c8a9-4aaa-4c72-942d-63f78b89f385 #
wurstbrot Jan 26, 2025
7ccfebb
chore: add link to FP in DefectDojo docs
wurstbrot Jan 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 1 addition & 3 deletions src/assets/YAML/default/BuildAndDeployment/Build.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,9 +48,7 @@ Build and Deployment:
A well defined build process lowers the possibility of errors during
the build process.
description: |
Sample evidence as an attribute in the yaml: The build process is defined in [REPLACE-ME Pipeline](https://replace-me/jenkins/job)
in the folder _vars_. Projects are using a _Jenkinsfile_ to use the
defined process.
A build process can be defined in code, for example in a `Jenkinsfile`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wanted to show how to document evidence. I think this is not the right place for it and causes confusions

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe 'Usage' page is the place to say some more about evidence and how to document this?

difficultyOfImplementation:
knowledge: 2
time: 3
Expand Down
9 changes: 5 additions & 4 deletions src/assets/YAML/default/Implementation/ApplicationHardening.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,14 +49,16 @@ Implementation:
iso27001-2022:
- Hardening is not explicitly covered by ISO 27001 - too specific
- 8.22
isImplemented: false
comments: ""
Contextualized Encoding:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think a description should be added to explain what Contextual encoding actually is.

A search for Application Hardening "Contextualized Encoding" mainly refers back to DSOMM.

Copy link
Contributor Author

@wurstbrot wurstbrot Jan 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It learned the the term Contextualized Encoding from @philippederyck .
What do you think about Output Encoding?

TSS Web describes it like this:

Every access to backend systems such as databases MUST be parameterized1, e.g. via prepared statements, OR mappers (e.g. Hibernate) when an API for this matter does exist.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have 0 context, but it sounds like you're trying to mash two concepts together.

Parametrization is an effective way to separate code and data (e.g., SQL statement and parameters, HTML template and variables, ...), which is crucial to be able to apply proper defenses.

Context-sensitive output encoding is for example used when inserting data into HTML pages, to avoid an HTML parser down the line from seeing data as code. The context-sensitive part relates to the fact that encoding is different based on which context the data ends up in (e.g., html element/html attribute/url/javascript/css block/css attribute).

For example, with SQLi, parametrization allows the construction of the statement's syntax before adding any data, which prevents injection (e.g., with a prepared statement or similar approach). For XSS, context-sensitive output encoding can be applied manually at output time, or the use of parametrization allows frameworks like Angular/React/Vue to apply this automatically.

Hope this helps.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, then I think I get it. Thanks @philippederyck :)👍

In terms of activities in DSOMM, I think we need to keep proper SQL parameterization separate from proper HTML escaping, @wurstbrot. Apart from that deep down it is all about swapping characters around, I don't see that these have much in common. These two activities are normally performed by different people (i.e. back-end and front-end developers, respectively).

I haven't found any other activities mentioning hibernate/entity framework (or other SQL libraries).

I suggest we split the Contextualized encoding into:

  • SQL Injection Defense
  • HTML Sanitization and Encoding

(or some other and better wording : )

@wurstbrot: Have you split activities before? Do you make any special considerations to backwards compatibilities, uuids etc?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion?

SQL Injection Defense

Description

If a system concatenates strings (some of which are based on user input) to build SQL queries, an attacker can manipulate the query to do other unintentional SQL commands as well.

Risk

Systems vulnerable to SQL injections may lead to data breaches, loss of data, unauthorized alteration of data, or complete database compromise or downtime.

Measure

  • Use parametrized queries (or prepared statements)
  • Use stored procedures
  • Use ORM (Object-Relational Mapping) tools that automatically handle input sanitization

Implementation Guide

HTML Sanitization and Encoding:

Description:

If input from any user is displayed on the web page, care must be taken in case this input contains HTML or other executable code. For example if user input is inserted in innerHTML, the code will be executed by the
browser.

Risk

Without properly sanitizing user input when rendering HTML, an attacker may gain control over the user session.

Malicious user input can execute arbitrary actions like stealing session cookies, redirecting users to malicious sites, or defacing the page. This can result in XSS attacks, loss of user trust, and potential data leaks.

Measure

  • Use modern frameworks such as React/Angular/Vue/Svelte. The default method
    renders data in a safe way.
  • If you are using bare bone JavaScript, use innerText/textContent
    instead of innerHTML when displaying data. Sanitize input data to
    only contain allowed characters.
  • Implement content security policies (CSP) to restrict the types of content
    that can be loaded and executed.

Implementation Guide

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem. Can I suggest 'Parameterize database queries'?
Just to give the context in the title

Copy link
Contributor Author

@wurstbrot wurstbrot Jan 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not only about database queries, if you reach out to an other service via XML, the signs '<', '>' needs to be encoded correctly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want me to split the existing Contextual encoding into two new activities, @wurstbrot (taking you comments into account)?

yes, thank you

Copy link

@vbakke vbakke Jan 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll do that. 👍
just want to make sure we are on the same page, first, so that we get it right

I agree that XML is part of the contextual encoding. I also agree that contextual encoding is one topic. But DSOMM is defining activities that a team shall be able to tick off when they are done, right.

Is it better to flip the question to find the best way separation?

What are the activities we want the teams to do, and what is the definition of done, what is the "acceptance criteria" for the activity to be considered complete?

Will this help us find the boundaries?

I definitely think that frontenders and backenders have two different activities to deal with, when it comes to contextual encoding.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

acceptance criteria: Implement a framework that ensures parameter encoding for all downstream interpreters (databases, HTML, URLs, etc.). Each parameter must be encoded according to the specific requirements of its target interpreter to prevent injection vulnerabilities.
The usage of a framework is recommended.

uuid: e1f37abb-d848-4a3a-b3df-65e91a89dcb7
risk:
The generation of interpreter directives from user-provided data poses difficulties and can introduce vulnerabilities to injection attacks.
measure: |
Implementing contextualized encoding, such as employing object-relational mapping tools or utilizing prepared statements, nearly removes the threat of injection vulnerabilities.
Implementing contextualized encoding fpr the next interpreter, such as employing object-relational mapping tools
or utilizing prepared statements, nearly removes the threat of injection vulnerabilities.

Also take into account a a secure by default UI framework, which performs automatic contextual encoding of outputs with potential malicious user input (e.g. angular).
difficultyOfImplementation:
knowledge: 2
time: 2
Expand All @@ -75,6 +77,7 @@ Implementation:
iso27001-2022:
- Hardening is not explicitly covered by ISO 27001 - too specific
- 8.22
comments: ""
App. Hardening Level 1:
uuid: cf819225-30cb-4702-8e32-60225eedc33d
risk:
Expand Down Expand Up @@ -155,7 +158,6 @@ Implementation:
- Hardening is not explicitly covered by ISO 27001 - too specific
- 8.22
isImplemented: false
evidence: ""
comments: ""
dependsOn:
- App. Hardening Level 1
Expand Down Expand Up @@ -189,7 +191,6 @@ Implementation:
- Hardening is not explicitly covered by ISO 27001 - too specific
- 8.22
isImplemented: false
evidence: ""
comments: ""
dependsOn:
- App. Hardening Level 2 (75%)
Expand Down
6 changes: 4 additions & 2 deletions src/assets/YAML/default/Implementation/InfrastructureHardening.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -511,9 +511,11 @@ Implementation:
risk:
Evil actors might be able to perform a man in the middle attack and sniff
confidential information (e.g. authentication factors like passwords)
measure:
measure: |-
By using encryption at the edge of traffic in transit, it is impossible
or at least harder to sniff credentials being outside of the organization.
or at least harder to sniff credentials or information being outside of the organization.

Useage of standard protocols like HTTPS is recommended.
difficultyOfImplementation:
knowledge: 2
time: 2
Expand Down
20 changes: 13 additions & 7 deletions src/assets/YAML/default/InformationGathering/Monitoring.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -291,15 +291,23 @@ Information Gathering:
iso27001-2022:
- Not explicitly covered by ISO 27001 - too specific
- 5.26
isImplemented: false
evidence: ""
comments: ""
Simple application metrics:
uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1
risk: Attacks on an application are not recognized.
measure:
Gathering of application metrics helps to identify incidents like brute
force attacks, login/logout.
measure: |-
Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include:
- Authentication attempts (successful/failed logins)
- Transaction volumes and patterns (e.g. orders, payments)
- API call rates and response times
- User session metrics
- Resource utilization

Example: An e-commerce application normally processes 100 orders per hour. A sudden spike to 1000 orders per hour could indicate either:
- A legitimate event (unannounced marketing campaign, viral social media post)
- A security incident (automated bulk purchase bots, credential stuffing attack)

By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response.
difficultyOfImplementation:
knowledge: 2
time: 2
Expand All @@ -315,8 +323,6 @@ Information Gathering:
- 12.4.1
iso27001-2022:
- 8.15
isImplemented: false
evidence: ""
comments: ""
Simple budget metrics:
uuid: f08a3219-6941-43ec-8762-4aff739f4664
Expand Down
55 changes: 17 additions & 38 deletions src/assets/YAML/default/TestAndVerification/Consolidation.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,35 +39,6 @@ Test and Verification:
- 5.13
- 5.10
tags: ["vuln-action", "defect-management"]
Fix based on severity:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you removed this. I think it is worth leaving is. It is an easy, and important, first stepping stone. We just need to make the text more similar to Treatment of defects with severity high or higher (44f2c8a9-4aaa-4c72-942d-63f78b89f385).

BTW, Fix based on accessibility (0c10a7f7-f78f-49f2-943d-19fdef248fed) depends on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Fix based on severity" is a duplicate of uuid:44f2c8a9-4aaa-4c72-942d-63f78b89f385 # Treatment of defects with severity high or higher. Therefore, it needs to be removed as it is the never activity.
I have changed the reference, thank you.

uuid: 38d1bd10-7b5f-4ae1-868c-0ec813285425
risk: |-
Overwhelming volume of security findings from automated testing tools. This might lead to ignorance of findings.
measure: |
Implement a very simple risk-based prioritization framework for vulnerability remediation based on the severity of the findings.

On level one, fix only critical findings.
difficultyOfImplementation:
knowledge: 2
time: 2
resources: 1
usefulness: 3
level: 1
implementation:
references:
samm2:
- I-DM-3-B
iso27001-2017:
- 16.1.4
- 8.2.1
- 8.2.2
- 8.2.3
iso27001-2022:
- 5.25
- 5.12
- 5.13
- 5.10
tags: ["vuln-action", "defect-management"]
Advanced visualization of defects:
uuid: 7a82020c-94d1-471c-bbd3-5f7fe7df4876
risk:
Expand Down Expand Up @@ -168,11 +139,19 @@ Test and Verification:
uuid: c1acc8af-312e-4503-a817-a26220c993a0
risk:
As false positive occur during each test, all vulnerabilities might be
ignored.
measure:
False positives are suppressed so they will not show up on the next
tests again. Most security tools have the possibility to suppress false positives.
A Vulnerability Management System might be used.
ignored. Specially, if tests are automated an run daily.
measure: |-
Findings from security tests must be triaged and outcomes persistend/documented to:
- Prevent re-analysis of known issues in subsequent test runs
- Track accepted risks vs false positives
- Enable consistent decision-making across teams

At this maturity level, a simple tracking system suffices - tools need only distinguish between "triaged" and "untriaged" findings, without complex categorization. Some tools refer to this as "suppression" of findings.

Samples for false positive handling:
- [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html)
- [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/)
- [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling]
wurstbrot marked this conversation as resolved.
Show resolved Hide resolved
difficultyOfImplementation:
knowledge: 1
time: 1
Expand Down Expand Up @@ -248,9 +227,8 @@ Test and Verification:
iso27001-2022:
- 8.8
- 5.25
isImplemented: false
evidence: ""
comments: ""
tags: ["vuln-action", "defect-management"]
comments: ""#
Treatment of defects with severity high or higher:
uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385
risk: Vulnerabilities with severity high or higher are not visible.
Expand All @@ -274,7 +252,7 @@ Test and Verification:
- 8.8
- 5.25
implementation: []
isImplemented: false
tags: ["vuln-action", "defect-management"]
evidence: ""
Treatment of defects with severity middle:
uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594
Expand All @@ -297,6 +275,7 @@ Test and Verification:
- 8.8
- 5.25
implementation: []
tags: ["vuln-action", "defect-management"]
Usage of a vulnerability management system:
uuid: 85ba5623-84be-4219-8892-808837be582d
risk:
Expand Down
2 changes: 1 addition & 1 deletion src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ Test and Verification:
risk:
Time pressure and ignorance might lead to false predictions for the test
intensity.
measure: The intensity of the used tools are not modified to safe time.
measure: The intensity of the used tools are not modified to save time.
difficultyOfImplementation:
knowledge: 1
time: 1
Expand Down
16 changes: 10 additions & 6 deletions src/assets/YAML/schemas/dsomm-schema-implementation.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -135,11 +135,17 @@
"iso27001-2022"
]
},
"isImplemented": {
"type": "boolean"
"teamsImplemented": {
"type": "array",
"items": {
"type": "object"
}
},
"evidence": {
"type": "string"
"teamsEvidence": {
"type": "array",
"items": {
"type": "object"
}
},
"comments": {
"type": "string"
Expand All @@ -155,8 +161,6 @@
"level",
"implementation",
"references",
"isImplemented",
"evidence",
"comments"
],
"additionalProperties": false
Expand Down