OWASP DSOMM

Level 1: Basic understanding of security practices: Centralized system logging
Risk:
Local stored system logs can be unauthorized manipulated by attackers or might be corrupt after an incident. In addition, it is hard to perform a aggregation of logs.
Measure:
By using centralized logging logs are protected against unauthorized modification.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Medium
Implementation:

Level 2: Adoption of basic security practices: Logging of security events
Description:
Implement logging of security relevant events. The following events tend to be security relevant:

Measure:
Security-relevant events like login/logout or creation, change, deletion of users should be logged.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Very High
Assessment:

Level 2: Adoption of basic security practices: Visualized logging
Risk:
System and application protocols are not visualized properly which leads to no or very limited logging assessment. Specially developers might have difficulty to read applications logs with unusually tools like the Linux tool 'cat'
Measure:
Protocols are visualized in a simple to use real time monitoring system. The GUI gives the ability to search for special attributes in the protocol.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: High
Resources: High
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Centralized application logging
Risk:
Local stored logs can be unauthorized manipulated by attackers with system access or might be corrupt after an incident. In addition, it is hard to perform an correlation of logs. This leads attacks, which can be performed silently.
Measure:
A centralized logging system is used and applications logs (including application exceptions) are shipped to it.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low

Level 5: Advanced deployment of security practices at scale: Correlation of security events
Risk
Detection of security related events with hints on different systems/tools/metrics is not possible.
Measure
Events are correlated on one system. For example the correlation and visualization of failed login attempts combined with successful login attempts.
Difficulty of Implementation
Knowledge: Very High (three or more disciplines)
Time: Very High
Resources: Very High
Usefulness
High

Level 5: Advanced deployment of security practices at scale: PII logging concept
Risk:
Personal identifiable information (PII) is logged and the privacy law (e.g. General Data Protection Regulation) is not followed.
Measure:
A concept how to log PII is documented and applied.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Low
Implementation:

Level 1: Basic understanding of security practices: Simple application metrics
Risk:
Attacks on an application are not recognized.
Measure:
Gathering of application metrics helps to identify incidents like brute force attacks, login/logout.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Implementation:

Level 1: Basic understanding of security practices: Simple budget metrics
Risk:
Not getting notified about reaching the end of the budget (e.g. due to a denial of service) creates unexpected costs.
Measure:
Cloud providers often provide insight into budgets. A threshold and alarming for the budget is set.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Implementation:

Level 1: Basic understanding of security practices: Simple system metrics
Risk:
Without simple metrics analysis of incidents are hard. In case an application uses a lot of CPU from time to time, it is hard for a developer to find out the source with Linux commands.
Measure:
Gathering of system metrics helps to identify incidents and specially bottlenecks like in CPU usage, memory usage and hard disk usage.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Assessment:
Are system metrics gathered?
Implementation:

Level 2: Adoption of basic security practices: Alerting
Risk:
Incidents are discovered after they happened.
Measure:
Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time:
Resources:

Level 2: Adoption of basic security practices: Monitoring of costs
Risk:
Not monitoring costs might lead to unexpected high resource consumption and a high invoice.
Measure:
Implement cost budgets. Setting of an alert threshold and sending out errors when it is reached. In the best case, a second threshold with a limit is set so that the cost can not go higher.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Medium
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Visualized metrics
Risk:
Not visualized metrics lead to restricted usage of metrics.
Measure:
Metrics are visualized in real time in a user friendly way.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Medium
Resources: Medium
Usefulness:
High

Level 3: High adoption of security practices: Advanced availability and stability metrics
Risk:
Trends and advanced attacks are not detected.
Measure:
Advanced metrics are gathered in relation to availability and stability. For example unplanned downtime's per year.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Medium
Usefulness:
Very High

Level 3: High adoption of security practices: Audit of system events
Risk:
System events (system calls) trends and attacks are not detected.
Measure:
Gathering of system calls.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Deactivation of unused metrics
Risk:
High resources are used while gathering unused metrics.
Measure:
Deactivation of unused metrics helps to free resources.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time:
Resources:

Level 3: High adoption of security practices: Grouping of metrics
Risk:
The analysis of metrics takes long.
Measure:
Meaningful grouping of metrics helps to speed up analysis.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Very High
Resources: Medium
Usefulness:
Medium

Level 3: High adoption of security practices: Targeted alerting
Risk:
People are bored (ignorant) of incident alarm messages, as they are not responsible to react.
Measure:
By the definition of target groups for incidents people are only getting alarms for incidents they are in charge for.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time:
Resources:

Level 4: Very high adoption of security practices: Advanced app. metrics
Risk:
People are not looking into tests results. Vulnerabilities not recolonized, even they are detected by tools.
Measure:
All defects from the dimension Test- and Verification are instrumented.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Medium
Usefulness:
Very High

Level 4: Very high adoption of security practices: Coverage and control metrics
Risk:
The effectiveness of configuration, patch and vulnerability management is unknown.
Measure:
Usage of Coverage- and control-metrics to show the effectiveness of the security program. Coverage is the degree in which a specific security control for a specific target group is applied with all resources.
The control degree shows the actual application of security standards
and security-guidelines. Examples are gathering information on anti-virus, anti-rootkits, patch management, server configuration and vulnerability management.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time:
Resources: Medium
Usefulness:
Very High
Implementation:

Level 4: Very high adoption of security practices: Defense metrics
Risk:
IDS/IPS systems like packet- or application-firewalls detect and prevent attacks. It is not known how many attacks has been detected and blocked.
Measure:
Gathering of defense metrics like TCP/UDP sources enables to assume the geographic location of the request. Assuming a Kubernetes cluster with an egress-traffic filter (e.g. IP/domain based), an alert might be send out in case of every violation. For ingress-traffic, alerting might not even be considered.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time:
Resources: Medium
Usefulness:
Very High

Level 4: Very high adoption of security practices: Screens with metric visualization
Risk:
Security related information is discovered too late during an incident.
Measure:
By having an internal accessible screen with a security related dashboards helps to visualize incidents.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low

Level 5: Advanced deployment of security practices at scale: Metrics are combined with tests
Risk:
Changes might cause high load due to programming errors.
Measure:
Metrics during tests helps to identify programming errors.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: High
Resources: Medium

Level 2: Adoption of basic security practices: Number of vulnerabilities/severity
Description:
Communication can be performed in a simple way, e.g. text based during the build process. This activity depends on at least one security testing implementation.
Risk:
Failing to convey the number of vulnerabilities by severity might undermine the effectiveness of product teams. This might lead to ignorance of findings.
Measure:
Measurement and communication of vulnerabilities per severity for components like applications. At least quarterly.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Number of vulnerabilities/severity/layer
Description:
Communication can be performed in a simple way, e.g. text based during the build process. This activity depends on at least one security testing implementation. Layers to consider (SCA):

Layers to consider SAST/DAST:

Risk:
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.
Measure:
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.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Patching mean time to resolution via PR
Risk:
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.
Measure:
Measurement and communication of patching Mean Time to Resolution (MTTR) in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis. This includes the measurement of the existence of a properly configured automated pull request (PR) tool (e.g., Dependabot or Renovate) in a repository. In addition, the measurement of the time from opening an automated PR to merging it.
Average time to patch is visualized per component/project/team.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Medium
Usefulness:
High

Level 3: High adoption of security practices: Fix rate per repo/product
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Generation of response statistics
Risk:
No or delayed reaction to findings leads to potential exploitation of findings.
Measure:
Creation and response statistics (e.g. Mean Time to Resolution) of findings. This is also referred to as Mean Time to Resolve.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: SLA per criticality
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 4: Very high adoption of security practices: Patching mean time to resolution via production
Risk:
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.
Measure:
Measurement and communication of the time from the availability of a patch to its deployment in production in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis. Average time to patch is visualized per component/project/team.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Medium