OWASP DSOMM

Level 1: Basic understanding of security practices: Ad-Hoc Security trainings for software developers
Risk:
Understanding security is hard and personnel needs to be trained on it. Otherwise, flaws like an SQL Injection might be introduced into the software which might get exploited.
Measure:
Provide security awareness training for all personnel involved in software development Ad-Hoc.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness:
High
Implementation:

Level 1: Basic understanding of security practices: Security consulting on request
Risk:
Not asking a security expert when questions regarding security appear might lead to flaws.
Measure:
Security consulting to teams is given on request. The security consultants can be internal or external.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Low
Resources: Low
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Each team has a security champion
Description:
Implement a program where each software development team has a member considered a “Security Champion†who is the liaison between Information Security and developers. Depending on the size and structure of the team the “Security Champion†may be a software developer, tester, or a product manager. The “Security Champion†has a set number of hours per week for Information Security related activities. They participate in periodic briefings to increase awareness and expertise in different security disciplines. “Security Champions†have additional training to help develop these roles as Software Security subject-matter experts. You may need to customize the way you create and support “Security Champions†for cultural reasons.
The goals of the position are to increase effectiveness and efficiency of application security and compliance and to strengthen the relationship between various teams and Information Security. To achieve these objectives, “Security Champions†assist with researching, verifying, and prioritizing security and compliance related software defects. They are involved in all Risk Assessments, Threat Assessments, and Architectural Reviews to help identify opportunities to remediate security defects by making the architecture of the application more resilient and reducing the attack threat surface. Source: OWASP SAMM
Risk:
No one feels directly responsible for security and the security champion does not have enough time to allocate to each team.
Measure:
Each team defines an individual to be responsible for security. These individuals are often referred to as 'security champions'
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Regular security training for all
Description:
Conduct security awareness training for all roles currently involved in the management, development, testing, or auditing of the software. The goal is to increase the awareness of application security threats and risks, security best practices, and secure software design principles. Develop training internally or procure it externally. Ideally, deliver training in person so participants can have discussions as a team, but Computer-Based Training (CBT) is also an option.
Course content should include a range of topics relevant to application security and privacy, while remaining accessible to a non-technical audience. Suitable concepts are secure design principles including Least Privilege, Defense-in-Depth, Fail Secure (Safe), Complete Mediation, Session Management, Open Design, and Psychological Acceptability. Additionally, the training should include references to any organization-wide standards, policies, and procedures defined to improve application security. The OWASP Top 10 vulnerabilities should be covered at a high level.
Training is mandatory for all employees and contractors involved with software development and includes an auditable sign-off to demonstrate compliance. Consider incorporating innovative ways of delivery (such as gamification) to maximize its effectiveness and combat desensitization.
Source: OWASP SAMM 2
Risk:
Understanding security is hard.
Measure:
Provide security awareness training for all internal personnel involved in software development on a regular basis like twice in a year for 1-3 days.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: Medium
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Regular security training of security champions
Risk:
Understanding security is hard, even for security champions.
Measure:
Regular security training of security champions.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: Medium
Resources: Medium
Assessment:
Process Documentation: TODO

Training Content: TOODO

Level 2: Adoption of basic security practices: Reward of good communication
Risk:
Employees are not getting excited about security.
Measure:
Good communication and transparency encourages cross-organizational support. Gamification of security is also known to help, examples include T-Shirts, mugs, cups, gift cards and 'High-Fives'.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Security code review
Description:

Risk:
Understanding security is hard.
Measure:
The following areas of code tend to have a high-risk of containing security vulnerabilities:

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

Level 3: High adoption of security practices: Conduction of build-it, break-it, fix-it contests
Risk:
Understanding security is hard, even for security champions and the conduction of security training often focuses on breaking a component instead of building a component secure.
Measure:
The build-it, break-it, fix-it contest allows to train people with security related roles like security champions the build, break and fix part of a secure application. This increases the learning of building secure components.
Difficulty of Implementation:
Knowledge:
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Office Hours
Risk:
Developers and Operations are not in contact with the security team and therefore do not ask prior implementation of (known or unknown) threats-
Measure:
As a security team, be open for questions and hints during defined office hours. x x d
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
High

Level 3: High adoption of security practices: Security Coaching
Risk:
Training does not change behaviour. Therefore, even if security practices are understood, it's likely that they are not performed.
Measure:
By coaching teams on security topics using for example the samman coaching method, teams internalize security practices as new habits in their development process.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: High
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Security-Lessoned-Learned
Risk:
After an incident, a similar incident might reoccur.
Measure:
Running a 'lessons learned' session after an incident helps drive continuous improvement. Regular meetings with security champions are a good place to share and discuss lessons learned.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
High

Level 3: High adoption of security practices: Simple mob hacking
Description:

Risk:
Understanding security is hard.
Measure:
Participate with your whole team in a simple mob hacking session organized by the Security Champion Guild. In the session the guild presents a vulnerable application and together you look at possible exploits. Just like in mob programming there is one driver and several navigators.
Difficulty of Implementation:
Knowledge:
Time: High
Resources: Low

Usefulness:
High
Implementation:

Level 4: Very high adoption of security practices: Aligning security in teams
Risk:
The concept of Security Champions might suggest that only he/she is responsible for security. However, everyone in the project team should be responsible for security.
Measure:
By aligning security Subject Matter Experts with project teams, a higher security standard can be achieved.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: Very High
Resources: Low
Implementation:

Level 4: Very high adoption of security practices: Conduction of collaborative team security checks
Risk:
Development teams limited insight over security practices.
Measure:
Mutual security testing the security of other teams project enhances security awareness and knowledge.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time: Very High
Resources: Medium
Usefulness:
Medium

Level 4: Very high adoption of security practices: Conduction of war games
Risk:
Understanding incident response plans during an incident is hard and ineffective.
Measure:
War Games like activities help train for incidents. Security SMEs create attack scenarios in a testing environment enabling the trainees to learn how to react in case of an incident.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time:
Resources: Very High
Usefulness:
High

Level 4: Very high adoption of security practices: Regular security training for externals
Risk:
Understanding security is hard.
Measure:
Provide security awareness training for all personnel including externals involved in software development on a regular basis.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: High
Usefulness:
Very High
Implementation:

Level 5: Advanced deployment of security practices at scale: Conduction of collaborative security checks with developers and system administrators
Risk:
Security checks by external companies do not increase the understanding of an application/system for internal employees.
Measure:
Periodically security reviews of source code (SCA), in which security SME, developers and operations are involved, are effective at increasing the robustness of software and the security knowledge of the teams involved.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High