The “Empower” phase is the final and most comprehensive step in the 3E framework. It focuses on empowering development teams with the necessary tools, processes, and knowledge to integrate security seamlessly into the software development lifecycle without the active involvement of security experts.
Following the foundational steps of “Educate” and “Embed,” this phase emphasizes effectively implementing and managing security requirements and threat modeling. By empowering teams, organizations can ensure that security is not just an added layer but a core component of their development process. Security champions, as defined in the “Embed” phase, serve as ideal owners of the activities described below.
Threat Modeling
Threat modeling is a crucial process for integrating Security by Design. Microsoft first popularized it through its Secure Development Lifecycle, and it has since gained widespread recognition. Threat modeling helps identify, assess, and mitigate security risks early in the software development lifecycle.
Threat Modeling Considerations
Threat modeling typically seeks to answer four fundamental questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
Popular methodologies like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) guide development teams in identifying threats. However, the effectiveness of manual threat modeling is often limited by the security knowledge of the practitioners involved.
In our experience, manual threat modeling processes typically take 40 – 120 hours to complete and require participation from multiple stakeholders. These time commitments can lead to significant pushback and derail the entire Security by Design program. Therefore, we highly recommend automating threat modeling to streamline the process and maintain development agility.
Organizations that use a threat model consistently and at scale can, by design, realize all four value drivers of security.
Start Your Security by Design
Journey Today
Gain instant access to our essential guide on Security by Design.
Click below to view or download your copy now.
Security Requirements Generation
The outcome of threat modeling is a set of countermeasures or controls, which become security requirements. Unfortunately, many organizations skip this crucial step, resulting in unaddressed vulnerabilities. It is essential to ensure that security requirements are actionable and integrated into the development process.
Criteria for Effective Security Requirements
For security requirements to be effective, they must be:
- Clear and Concise: Easily understood and implemented.
- Relevant: Directly applicable to the specific context of the application.
- Actionable: Specific steps that can be taken to mitigate identified risks.
- Testable: Capable of being validated through testing.
- Explained: Providing context on the underlying threat and its mitigation.
- Compliant: Aligning with relevant compliance obligations.
In our experience, security requirements are more likely to be addressed if tracked inside a product development team’s already-used tool, such as JIRA. Using a system to track security requirements also helps create audit trails for regulatory compliance.
Static Requirements Lists
While static lists like the OWASP Top 10 or NIST 800-53 provide a good starting point, they are often too generic and not directly actionable. Security requirements should be tailored to each application to ensure they are relevant and effective.
Secure Coding Guidelines
Secure coding guidelines are another common approach, but they often suffer from being too broad and not traceable. Instead, integrating language-specific implementation guidelines into security requirements can provide developers with more practical and actionable guidance.
Process Change
Implementing Security by Design often requires significant changes to existing development processes. Successful rollouts necessitate clear, specific mapping of how the existing process will change and who will be responsible for each step.
The following is an example of a process flow diagram illustrating the roles and responsibilities in a threat modeling platform rollout:
- Identify Assets: Determine the valuable assets in the application.
- Identify Threats: Use threat modeling methodologies to identify potential threats.
- Determine Mitigations: Develop countermeasures to mitigate identified threats.
- Implement Security Requirements: Integrate these countermeasures into the development process as security requirements.
- Validate Mitigations: Test the implemented security measures to ensure they effectively mitigate the threats, for example, by using Static Analysis Security Testing (SAST) tools.
- Review and Iterate: Continuously review and improve the threat modeling process and security requirements based on feedback and new threats.
Figure 1: Process flow diagram outlining responsibilities in a threat modeling platform rollout
Detailed Steps for Implementation
- Educate: Ensure all team members understand the basics of security threats and the importance of threat modeling. Provide training sessions and resources.
- Tool Selection: Choose the tools for automated threat modeling that fit your development workflow.
- Pilot Program: Start with a small, manageable project to pilot the threat modeling process and security requirement generation.
- Feedback Loop: Gather feedback from the pilot program to refine the process and address any challenges encountered.
- Rollout: Gradually extend the process to larger projects and additional teams, ensuring continuous support and adjustment based on feedback.
- Monitoring and Reporting: Establish a robust monitoring and reporting mechanism to track the effectiveness of implemented security measures and make data-driven decisions for improvements.
Automation in Threat Modeling
Automating threat modeling helps eliminate bottlenecks and enhances the agility of the development process. Developer-centric threat modeling tools are more efficient and scalable than manual methods.
These tools integrate seamlessly into the development workflow, enabling continuous and consistent threat analysis.
For a comprehensive understanding, refer to this whitepaper, which outlines the advantages of developer-centric threat modeling over traditional methods.
Figure 2: Comparison of manual and automated approaches in threat modeling (visit: https://www.securitycompass.com/threat-modeling/free-threat-modeling-course/)
Conclusion
The “Empower” phase of the 3E framework is crucial for ensuring that security is deeply integrated into the software development lifecycle. Organizations can build more secure and resilient software by implementing threat modeling and generating actionable security requirements.
Empowering development teams with the right tools, processes, and knowledge ensures that security is not just an afterthought but a fundamental aspect of development. This comprehensive approach to security helps organizations stay ahead of potential threats and build trust with their users and stakeholders.
By following the steps outlined in this phase, organizations can ensure that security is integral to their development process, leading to more robust and secure software systems. The “Empower” phase, focusing on automation, effective security requirement generation, and continuous improvement, is the key to sustaining a strong security posture in the dynamic software development landscape.