Implementation

Introduction

Secure Build

Maturity 1 - Build process is repeatable and consistent Maturity 2 - Build process is optimized and fully integrated into the workflow Maturity 3 - Build process helps prevent known defects from entering the production environment.

Build Process The build process is defined and consistent. The build process is fully automated and does not require intervention by the developer. Security defects may trigger the build to stop executing

Software Dependencies All application dependencies are identified and documented All components and dependencies are periodically reviewed for known security vulnerabilities and licensing issues Components and dependencies are independently scanned for vulnerabilities

Secure Deployment

Maturity 1 - Deployment processes are fully documented Maturity 2 - Deployment processes include security verification milestones Maturity 3 - Deployment process is fully automated and incorporates automated verification of all critical milestones

Deployment Process Deployment is automated or done by someone other than the developer. Integration of security verification in deployment (e.g. binary static code analysis / AV scan) Integrity of the code is verified prior to deployment

Secret Management Production secrets are encrypted and not handled by developers Secrets are dynamically included during the deployment process Files and repositories are checked periodically for secrets that should be protected

Defect Management

Maturity 1 - All defects are tracked within each project Maturity 2 - Defect tracking used to influence the deployment process Maturity 3 - Defect tracking across multiple components is used to help reduce the number of new defects

Defect Tracking (Flaws/Bugs/Process) Track all defects Assign SLA based on security rating of the defect Measure and enforce compliance with the SLA

Metrics and Feedback/Learning Calculate and share basic metrics, such as total counts Calculate more advanced metrics that include new issue velocity, remediation speed metrics, and trends. Use trend analysis to influence changes in the Design and Implementation phase across multiple projects.

During several presentations on the subject of SAMM and application security, in general, I used to ask the audience members to vote on the different Business Functions in terms of impact on the security of software. In virtually all sessions Governance got the lowest scores, which should surprise no one. Frankly, if you work for an organization responsible for developing only a handful of custom applications, I would agree with that notion. However, as the number of developed applications increases and organizations get larger, Governance becomes indispensable.

One important factor to keep in mind is that for Application Security, the emphasis on Governance goes beyond maximizing the number of security checks and focuses just as much on optimizing security. This is done by emphasizing controls that impact the entire organization over the seemingly endless hunt for software defects. The three security practices under Governance should help illustrate new ways of thinking about Application Security Governance, and will hopefully help change some of the well-earned reputations of Governance as bureaucratic and out of step with development and security.

Strategy & Metrics

This practice is intended to form the foundation for all application security activities. The days when security could be sold and measured using words like “breach” or “security incident” are long gone, and understandable companies are requiring more from their security teams. Most importantly, organizations expect security to be strategic and proactive, and they want security to be measured. In this regards, SAMM’s guidance follows the following maturity guidance:

• Maturity 1 - Identify objectives and means of measuring the effectiveness of the security program.
• Maturity 2 - Establish a unified strategic roadmap for software security within the organization.
• Maturity 3 - Align security efforts with relevant organizational indicators and asset values.

To achieve this, the Security Practice identifies two important activities that must work together:

Create and Promote Organizations should start by identifying an organization’s drivers and most significant risks, and then determining how Application Security can best support them. Priorities should go beyond external considerations such as regulatory compliance and revenue, and also focus on priorities that may be uniquely related to the software development, such as standardization, the supportability of applications, uptime, and maximizing effectiveness of development teams. In most cases, a well designed Application Security strategy will be able to align with all objectives and find a significant amount of overlap with software development. Finally, even the best Application Security strategy can be made ineffective if nobody knows about it. Promoting the overall strategy organization-wide is a critical step in ensuring its effectiveness.

Measure and Improve When it comes to most organizations, they generally start metrics programs with measuring results, such as defect counts or backlog statistics. However, this would always provide an incomplete picture that focuses too much on security and not enough of the business of writing software. Other important considerations described by SAMM include measures of effort and environment, which provide measures of how much time is dedicated to security as well as measures of the landscape in which Application Security is implemented. Once combined with measurements of results metrics will begin to tell a more complete story and enable organizations to recognize and promote efficiency as well as security. Eventually, metrics and KPIs can be used to help influence future Application Security initiatives and help substantiate future investments in tools and developer resources.

Policy & Compliance

This practice is exactly what it sounds like and focuses on internal Policies and Standards, as well as external compliance requirements. While this general expectation has been a part of virtually every security and maturity framework, in SAMM 2 it has taken an important step forward in terms of making these requirements more aligned with the Agile methodology as well as current DevOps tools. Additionally, maturity roadmap now goes beyond simply having policies and focuses more on how these policies are promoted in the organization:

• Maturity 1 - Identify and document governance and compliance drivers relevant to the organization.
• Maturity 2 - Establish an application-specific security and compliance baseline.
• Maturity 3 - Measure adherence to policies, standards, and 3rd-party requirements.

The two activity streams are Policy and Standards and Compliance Management, and for this summary can be described together. One of the most important changes in this practice is the suggestion that Security Policies and Compliance Requirements should be published as Run Books or Test Scripts instead of the traditional long-form text. These documents should be formatted and designed in a way that would make it easy for developers and QA to understand and design appropriate application requirements and fully automated tests. The ultimate goal is to make an understanding of policies and compliance requirements easier, as well as potentially automate the process of verifying compliance by leveraging QA.

Education & Guidance

Dollar for dollar, the biggest improvement in Information Security can be made through additional and more effective training. While most organizations recognize the value of training, SAMM guidance will help move the basic concepts like membership to a growing number of CBT “all-you-can-eat” too much more formal programs including mandatory training requirements for different roles as well as platform certifications before giving full access to the production environment. Another important aspect of this practice is Organizational culture, which is intended to result in additional training opportunities as well as create an overall culture of security among developers. Together, these provide the following set of maturity level objectives:

• Maturity 1 - Offer staff access to resources around the topics of secure development and deployment.
• Maturity 2 - Educate all personnel in the software life-cycle with technology and role-specific guidance on secure development.
• Maturity 3 - Develop in-house training programs facilitated by developers across different teams

Training and Awareness This activity focuses on ways organizations can evolve their application security training programs, not to be confused with general security awareness that would apply to all employees. This activity is best reviewed for maturity expectations based on the overall size of the organization and the number of different applications being developed. Larger organizations will be best served by setting their targets at higher maturity.

Organization and Culture While most organizations began implementing programs such as “Security Champion”, the majority of them lack formal structure. This activity describes how large organizations can evolve these programs into tighter partnerships with organizations software architects and aligning their priorities. At highest maturity levels, these programs should evolve into Centers of Excellence where different teams that ordinarily would not have much contact could share knowledge and experience, which will inevitably result in fewer defects and more security applications.

Summary

Hopefully, this summary helped peak interest in Governance and supported the goal of showing how it can be aligned with software development. The next blog will describe the most significant changes and objectives of the Design Business Function.