Provide security awareness training for all personnel involved in software development Ad-Hoc.
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.
Security consulting to teams is given on request. The security consultants can be internal or external.
Risk: Not asking a security expert when questions regarding security appear might lead to flaws.
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.
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.
Regular security training of security champions.
Risk: Understanding security is hard, even for security champions.
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'.
Risk: Employees are not getting excited about security.
The following areas of code tend to have a high-risk of containing security vulnerabilities:
Risk: Understanding security is hard.
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.
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.
By coaching teams on security topics using for example the samman coaching method, teams internalize security practices as new habits in their development process.
Risk: Training does not change behaviour. Therefore, even if security practices are understood, it's likely that they are not performed.
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.
Risk: After an incident, a similar incident might reoccur.
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.
Additional information:
Risk: Understanding security is hard.
By aligning security Subject Matter Experts with project teams, a higher security standard can be achieved.
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.
Mutual security testing the security of other teams project enhances security awareness and knowledge.
Risk: Development teams limited insight over security practices.
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.
Risk: Understanding incident response plans during an incident is hard and ineffective.
Provide security awareness training for all personnel including externals involved in software development on a regular basis.
Risk: Understanding security is hard.
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.
Risk: Security checks by external companies do not increase the understanding of an application/system for internal employees.