Historically, companies have focused on implementing security controls around physical infrastructure, networks, servers and endpoints. This focus is potentially because many different technological solutions exist to help to protect these assets which can be managed in a centralized way using dashboards and remote consoles.
Examples of these kinds of solutions include next generation firewalls, anti-virus and advanced threat protection (ATP) tools, and Security Incident and Event Monitoring (SIEM) supported by threat intelligence processes.
However, the maturity level of security in the software development lifecycle (SDLC) remains some steps behind and I believe there are a few reasons for this.
Lack of time and the need to meet a deadline is always the first complaint when discussing implementing security controls beyond those which are default features in development frameworks, (for example).
The second complaint is around budget, especially if the development team is outsourced and are billing by the hour. Since security has not historically been considered a basic property of software code in the same way that performance and readability would be, it is still seen as an extra cost.
The third complaint is the lack of knowledge of many developers about basic security controls and the impact of the major security flaws already documented by security community. Hopefully all developers know about attacks such as SQL Injection, Cross-Site Scripting, Session Hijacking, etc. However, is quite clear that sometimes developers are missing the deep knowledge about the real consequences of successful exploitation of those flaws. For example, a developer may know that a SQL Injection attack may lead to data being stolen from a database but not be aware of other risks posed by the same attack such as getting a remote command shell on the server where the vulnerable database is hosted.
There are other examples of barriers to implementing a secure software development lifecycle, but with the increase in data breaches related to application vulnerabilities and the rise of known penalties such as those defined by GDPR, it is now easier to demonstrate the business case for companies to increase the maturity level of their secure development processes.
OWASP (the Open Web Application Security Project) is an international non-profit organization dedicated to application security. It provides very valuable resources ranging from tools to frameworks to documentation, all developed by a dedicated network of volunteers from around the world. Nowadays, it is the best repository where you can find all the information needed to raise the level of knowledge and skill of your technical and management teams.
The OWASP Top 10, for example, which is updated roughly every three years, is an excellent document to build awareness of the most common application vulnerabilities which have been noted in the last few years and the right controls and mitigations which can be used to avoid and fix them. However, it is clear that it is vital that security is included as early in the SLDC as possible since the later that security is introduced, the more expensive issues are to fix. The Top 10 project is probably not the most ideal project for including security early on in the SDLC nor is it comprehensive enough to help an organization reshape their SLDC to include security at each stage.
As such, I would like to discuss the OWASP Software Assurance Maturity Model (SAMM) project. This is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. This model defines four different Business Functions related to Software Development Lifecycle which the organization needs to address: Governance, Construction, Verification and Deployment.
These four Business Functions can be divided in 12 different Security Practices:
· Governance (Business Function)
o Strategy & Metrics (Security Practices)
o Policy & Compliance (Security Practices)
o Education & Guidance (Security Practices)
· Construction (Business Function)
o Threat Assessment (Security Practices)
o Security Requirements (Security Practices)
o Secure Architecture (Security Practices)
· Verification (Business Function)
o Design Review (Security Practices)
o Code Review (Security Practices)
o Security Testing (Security Practices)
· Deployment (Business Function)
o Vulnerability Management (Security Practices)
o Environment Hardening (Security Practices)
o Operational Enablement (Security Practices)
These twelve security practices can each help to increase the maturity level of the organization’s SDLC, in a measurable way. Implementing these practices can be planned step by step and the resulting changes and improvements can be monitored. Therefore, it represents a complete process that can be integrated into the SDLC and ensures that security is considered from the very first stages of the planning through to the application being deployed to production and on through the post-deployment phase as well, with ongoing vulnerability management as a continuous practice.
The activities related to each security practice are listed below:
· Governance
o Strategy & Metrics
§ Estimate overall business risk profile
§ Build and maintain assurance program roadmap
§ Classify data and applications based on business risk
§ Establish and measure per-classification security goals
§ Conduct periodic industry-wide cost comparisons
§ Collect metrics for historic security spend
o Policy & Compliance
§ Identify and monitor external compliance drivers
§ Build and maintain compliance guidelines
§ Build policies and standards for security and compliance
§ Establish project audit practice
§ Create compliance gates for projects
§ Adopt solution for audit data collection
o Education & Guidance
§ Conduct technical security awareness training
§ Build and maintain technical guidelines
§ Conduct role-specific application security training
§ Utilize security coaches to enhance project teams
§ Create formal application security support portal
§ Establish role-based examination/certification
· Construction
o Threat Assessment
§ Build and maintain application-specific threat models
§ Develop attacker profile from software architecture
§ Build and maintain abuse-care models per project
§ Adopt a weighting system for measurement of threats
§ Explicitly evaluate risk from third-party components
§ Elaborate threat models with compensating controls
o Security Requirements
§ Derive security requirements from business functionality
§ Evaluate security and compliance guidance for requirements
§ Build an access controls matrix for resources and capabilities
§ Specify security requirements based on known risks
§ Build security requirements into supplier agreements
§ Expand audit program for security requirements
o Secure Architecture
§ Maintain list of recommended software frameworks
§ Explicitly apply security principles to design
§ Identify and promote security services and infrastructure
§ Identify security design patterns from architecture
§ Establish formal reference architectures and platforms
§ Validate usage of frameworks, patterns and platforms
· Verification
o Design Review
§ Identify software attack surface
§ Analyze design against known security requirements
§ Inspect for complete provision of security mechanisms
§ Deploy design review services for project teams
§ Develop data-flow diagrams for sensitive resources
§ Establish releases gates for design review
o Code Review
§ Create review checklists from known security requirements
§ Perform point-review of high-risk code
§ Utilize automated code analysis tools
§ Integrate code analysis into development process
§ Customize code analysis for application-specific concerns
§ Establish release gates for code review
o Security Testing
§ Derive test cases from known security requirements
§ Conduct penetration testing on software releases
§ Utilize automated security testing tools
§ Integrate security testing into development process
§ Employ application-specific security testing automation
§ Establish release gates for security testing
· Deployment
o Vulnerability Management
§ Identify point of contact for security issues
§ Create informal security response team
§ Establish consistent incident response process
§ Adopt a security issue disclosure process
§ Conduct root cause analysis for incidents
§ Collect per-incident metrics
o Environment Hardening
§ Maintain operational environment specification
§ Identify and install critical security upgrades and patches
§ Establish routine patch management process
§ Monitor baseline environment configuration status
§ Identify and deploy relevant operations protection tools
§ Expand audit program for environment configuration
o Operational Enablement
§ Capture critical security information for deployment
§ Document procedures for typical application alerts
§ Create per-release change management procedures
§ Maintain formal operational security guides
§ Expand audit program for operational information
§ Perform code signing for application components
Whilst there are a lot of activities to implement here, it is important to execute at the correct pace. If activities are implemented too fast without monitoring metrics to check if each phase was successful and has been integrated into the organization’s processes, the implementation will ultimately fail and the security and other value benefits will not be realized.
It is particularly important to note that the activities in each security practice are ordered based on maturity meaning that an organization should initially focus on implementing the first activities across all the different practices and then once these initial activities are operating correctly, go back and start implementing the next activities, again across each the twelve practices.
The SAMM project documentation even provides metrics for each activity, staff needed and the estimated time that will be required per year for each member of the team to help the end-user ensure that they are implementing each activity in the correct way.
Note that SAMM isn’t the only methodology that can be used to improve the maturity level of a secure development process. Some examples of similar methodologies are BSIMM, ISMM (for IoT environments) or DASMM, this last one representing the implementation a combination of controls from both BSIMM and SAMM at the same time.
Independent of the methodology, is important to understand that everything must be grounded in the solid foundations of a good strategy, metrics to monitor performance and policies and procedures sponsored by management to ensure compliance with the new processes.
Ultimately, the key to success will be employee education to help everyone to understand the real need to improve the maturity level of secure development and to keep everyone updated and aware of their own role in the process.
Always remember to carefully monitor the entire process and establish SMART (Specific, Measureable, Achievable, Relevant, Timely) goals for each step. A good approach to adopt to help with the transformation is the Objectives and key results (OKR) methodology as this will make it easier to identify what needs to be achieved at each stage and what result is expected. The information for this is already provided by the SAMM methodology. There is a link to information on OKR in the references section.
Increasing the maturity of your Secure SDLC will be hard work, but the results should be worthwhile and be shown by an improvement in penetration testing results and decrease reduction in the risk of compromise via application vulnerabilities.
References:
OWASP – https://owasp.org
BSIMM – https://www.bsimm.com/
DASMM – https://duo.com/blog/rsac-2018-building-a-software-security-maturity-program
