OWASP DSOMM

Level 1: Basic understanding of security practices: App. Hardening Level 1 (50%)
Description:
To tackle the security of code developed in-house, OWASP offers an extensive collection of Cheatsheets 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 offers 3 distinct maturity levels covering both in-house software development and third party supplier security.
Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process.
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.
In case of internal development and if the organization maps Features to Epics, the Security Knowledge Framework can be used to facilitate this process by leveraging its questionnaire function, shown below.
Source: OWASP Project Integration
Risk:
Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Measure:
Following frameworks like the

in all applications provides a good baseline. Implement 50% of the recommendations.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 1: Basic understanding of security practices: Contextualized Encoding
Description:
Bear in mind that utilizing frameworks is a recommended approach; however, they can develop known security weaknesses over time. Diligent and regular patching is crucial.
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.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High

Level 2: Adoption of basic security practices: App. Hardening Level 1
Description:
To tackle the security of code developed in-house, OWASP offers an extensive collection of Cheatsheets 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 jump-start 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 offers 3 distinct maturity levels covering both in-house software development and third party supplier security.
Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process.
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.

In case of internal development and if the organization maps Features to Epics, the Security Knowledge Framework can be used to facilitate this process by leveraging its questionnaire function, shown below.
Source: OWASP Project Integration
Risk:
Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Measure:
Following frameworks like the

in all applications provides a good baseline. Implement 95%-100% of the recommendations.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: App. Hardening Level 2 (75%)
Risk:
Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Measure:
Following frameworks like the

Implement 75% of the recommendations.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 4: Very high adoption of security practices: App. Hardening Level 2
Risk:
Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Measure:
Following frameworks like the

Implement 95%-100% of the recommendations.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 5: Advanced deployment of security practices at scale: App. Hardening Level 3
Risk:
Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Measure:
Following frameworks like the

Implement 95%-100% of the recommendations.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: Very High
Resources: Medium
Usefulness:
Very High
Implementation:

Level 1: Basic understanding of security practices: Versioning
Risk:
Deployment of untracked artifacts.
Measure:
Version artifacts in order to identify deployed features and issues. This includes application and infrastructure code, jenkins configuration, container and virtual machine images.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High

Level 2: Adoption of basic security practices: Require a PR before merging
Risk:
Intentional or accidental alterations in critical branches like main (or master).
Measure:
Define source code management system policies (e.g. branch protection rules, mandatory code reviews from at least one person, ...) to ensure that changes to critical branches are only possible under defined conditions. These policies can be implemented at repository level or organization level, depending on the source code management system.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Block force pushes
Risk:
Misuse of force push can lead to loss of work. It may overwrite remote
branches without warning, potentially erasing valuable contributions from team members. This can disrupt collaboration, cause data loss, and create confusion in the development process.
Bypassing the pull request process might remove an important code review step. This increases the risk of merging low-quality or buggy code into the main branch, potentially introducing bugs in the codebase.
Measure:
Mandate blocking of force pushes in the version control platform.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Dismiss stale PR approvals
Risk:
Intentional or accidental alterations in critical branches like main (or master) through post-approval code additions.
Measure:
Implement a policy where any commits made after a pull request has been approved automatically revoke that approval, necessitating a fresh review and re-approval process.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Require status checks to pass
Risk:
Organizations risk introducing broken builds, quality issues, and security vulnerabilities into their codebase.
Measure:
Mandate passing of security related specified status checks, like successful builds or static application security tests, before proceeding.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 4: Very high adoption of security practices: .gitignore
Risk:
Unintended leakage of secrets, debug, or workstation specific data
Measure:
.gitignore files help prevent accidental commits of secrets, debug, or workstation specific data
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low

Level 5: Advanced deployment of security practices at scale: Local development linting & style checks performed
Risk:
Insecure or unmaintainable code base.
Measure:
Integrate static code analysis tools in IDEs.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Medium
Implementation:

Level 1: Basic understanding of security practices: MFA for admins
Risk:
One factor authentication is more vulnerable to brute force attacks and is considered less secure.
Measure:
Two ore more factor authentication for all privileged accounts on systems and applications

Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 1: Basic understanding of security practices: Simple access control for systems
Risk:
Attackers a gaining access to internal systems and application interfaces
Measure:
All internal systems are using simple authentication
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High
Implementation:

Level 1: Basic understanding of security practices: Usage of edge encryption at transit
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:
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.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High

Level 2: Adoption of basic security practices: Applications are running in virtualized environments
Risk:
Through a vulnerability in one service on a server, the attacker gains access to other services running on the same server.
Measure:
Applications are running in a dedicated and isolated virtualized environments.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources:
Usefulness:
High

Level 2: Adoption of basic security practices: Backup
Risk:
If errors are experienced during the deployment process you want to deploy an old release. However, due to changes in the database this is often unfeasible.
Measure:
Performing automated periodical backups are used. Backup before deployment can help facilitate deployments whilst testing the backup restore processes.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Baseline Hardening of the environment
Risk:
Using default configurations for a cluster environment leads to potential risks.
Measure:
Harden environments according to best practices. Level 1 and partially level 2 from hardening practices like 'CIS Kubernetes Bench for Security' should be considered.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: High
Resources: Medium
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Isolated networks for virtual environments
Risk:
Virtual environments in default settings are able to access other virtual environments on the network stack. By using virtual machines, it is often possible to connect to other virtual machines. By using docker, one bridge is used by default so that all containers on one host can communicate with each other.
Measure:
The communication between virtual environments is controlled and regulated.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High
Implementation:

Level 2: Adoption of basic security practices: MFA
Risk:
One factor authentication is more vulnerable to brute force attacks and is considered less secure.
Measure:
Two ore more factor authentication for all accounts on all (important) systems and applications
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Usage of an security account
Risk:
Having security auditing in the same account as infrastructure and applications at the cloud provide might cause evil administrators (or threat actors taking over an account of an administrator) to alter evidence like audit logs.
Measure:
Usage of a separate account dedicated for security activities.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: High
Usefulness:
Very High

Level 2: Adoption of basic security practices: Usage of encryption at rest
Risk:
Evil actors might be able to access data and read information, e.g. from physical hard disks.
Measure:
By using encryption at rest, it is impossible or at least harder to to read information.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High

Level 2: Adoption of basic security practices: Usage of test and production environments
Risk:
Security tests are not running regularly because test environments are missing
Measure:
A test and a production like environment is used
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources:
Usefulness:
Very High

Level 2: Adoption of basic security practices: Virtual environments are limited
Risk:
Denial of service (internally by an attacker or unintentionally by a bug) on one service effects other services
Measure:
All virtual environments are using resource limits on hard disks, memory and CPU
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: High
Usefulness:
High

Level 3: High adoption of security practices: Filter outgoing traffic
Risk:
A compromised infrastructure component might try to send out stolen data.
Measure:
Having a whitelist and explicitly allowing egress traffic provides the ability to stop unauthorized data leakage.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High
Usefulness:
Medium
Implementation:

Level 3: High adoption of security practices: Immutable infrastructure
Risk:
The availability of IT systems might be disturbed due to components failures
Measure:
Redundancies in the IT systems
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Infrastructure as Code
Risk:
No tracking of changes in systems might lead to errors in the configuration. In additions, it might lead to unauthorized changes. An examples is jenkins.
Measure:
Systems are setup by code. A full environment can be provisioned. In addition, software like Jenkins 2 can be setup and configured in in code too. The code should be stored in a version control system.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time:
Resources: Very High
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Limitation of system events
Risk:
System events (system calls) can lead to privilege escalation.
Measure:
System calls are limited.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Implementation:

Level 3: High adoption of security practices: Role based authentication and authorization
Risk:
Everyone is able to get unauthorized access to information on systems or to modify information unauthorized on systems.
Measure:
The usage of a (role based) access control helps to restrict system access to authorized users.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Usage of internal encryption at transit
Risk:
Evil actors within the organization of traffic in transit might be able to perform a man in the middle attack and sniff confidential information (e.g. authentication factors like passwords)
Measure:
By using encryption internally, e.g. inside of a cluster, it is impossible or at least harder to sniff credentials.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: High
Usefulness:
Very High

Level 3: High adoption of security practices: Usage of security by default for components
Risk:
Components (images, libraries, applications) are not hardened.
Measure:
Hardening of components is important, specially for image on which other teams base on. Hardening should be performed on the operation system and on the services inside (e.g. Nginx or a Java-Application).
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: WAF baseline
Description:
Begin with the WAF in a monitoring state to understand the traffic and threats. Progressively enforce blocking actions based on intelligence gathered, ensuring minimal disruption to legitimate traffic.
Risk:
Vulnerable input, such as exploits, can infiltrate the application via numerous entry points, posing a significant security threat.
Measure:
Implementing a web application firewall (WAF) is a critical security control. At a baseline level, the objective is to finely balance the reduction of false positives, maintaining user experience, against a potential increase in the less noticeable false negatives.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: High
Usefulness:
High

Level 4: Very high adoption of security practices: Hardening of the Environment
Risk:
Using default configurations for a cluster environment leads to potential risks.
Measure:
Harden environments according to best practices. Level 2 and partially level 3 from hardening practices like 'CIS Kubernetes Bench for Security' should be considered.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: Very High
Resources: Medium
Usefulness:
High
Implementation:

Level 4: Very high adoption of security practices: Production near environments are used by developers
Risk:
In case an errors occurs in production, the developer need to be able to create a production near environment on a local development environment.
Measure:
Usage of infrastructure as code helps to create a production near environment. The developer needs to be trained in order to setup a local development environment. In addition, it should be possible to create production like test data. Often personal identifiable information is anonymized in order to comply with data protection laws.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High
Usefulness:
Very High

Level 4: Very high adoption of security practices: Usage of a chaos monkey
Risk:
Due to manual changes on a system, they are not replaceable anymore. In case of a crash it might happen that a planned redundant system is unavailable. In addition, it is hard to replay manual changes.
Measure:
A randomized periodically shutdown of systems makes sure, that nobody will perform manual changes to a system.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time:
Resources:
Usefulness:
High

Level 4: Very high adoption of security practices: WAF medium
Description:
Maintain the WAF in alert mode initially to ensure a comprehensive understanding of potential threats. With a medium-level configuration, the WAF settings are refined for greater precision in threat detection, with a stronger emphasis on security without significantly impacting legitimate traffic.
Risk:
The threat from malicious inputs remains high, with exploits seeking to exploit any vulnerabilities present at the various points of entry to the application.
Measure:
A WAF deployed with a medium level of protection strengthens the security posture by striking a more advanced balance between the detection of genuine threats and the minimization of false alarms.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time:
Resources: Very High
Usefulness:
High

Level 5: Advanced deployment of security practices at scale: Microservice-architecture
Risk:
Monolithic applications are hard to test.
Measure:
A microservice-architecture helps to have small components, which are more easy to test.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time:
Resources:
Usefulness:
Low

Level 5: Advanced deployment of security practices at scale: WAF Advanced
Description:
The advanced WAF setup is designed to ensure all data is in the correct format and any superfluous input parameters are automatically rejected. It includes machine learning algorithms to detect anomalies, custom-developed rules for real-time traffic analysis, and seamless integration with existing security infrastructures to adapt to the ever-changing threat landscape.
Risk:
The presence of sophisticated threats necessitates a robust defense strategy where application inputs are meticulously scrutinized for security breaches, including advanced persistent threats and zero-day vulnerabilities.
Measure:
An advanced WAF protection level includes rigorous input validation, rejecting any parameters not explicitly required, and custom rule sets that are dynamically updated in response to emerging threats.
Difficulty of Implementation:
Knowledge:
Time:
Resources:
Usefulness:
Very High