Design

Introduction

The design business function holds one of the biggest contradictions in the information security industry. When teams are busy (and let’s be honest, most teams are) they don’t have time for activities such as Threat Modeling or documenting security or architecture requirements. However, these are exactly the activities that could help make teams less busy by allowing organizations make smarter decisions and apply more effective prioritization to determine which security defects require remediation. Like many other proactive security controls, these activities may not have an immediate impact on the security of the software. Howerver, if implemented well they could have a significant long-term impact, especially when applied to larger environments with hundreds or even thousands of applications.

Threat Assessment

This security practice has a lot of similarities to Risk Assessments. Like Risk Assessments, there are many opinions on how to do it well, and most teams view the process of going through this assessment as tedious and often XXXXXXXXXXXXX

Maturity 1 - Best-effort identification of high-level threats to the organization and individual projects. Maturity 2 - Standardization and enterprise-wide analysis of software-related threats within the organization Maturity 3 - Pro-active improvement of threat coverage throughout the organization

Application Risk Profile Organizations should start by mapping out different applications against common and easy to ascertain risks, such as regulatory compliance, data sensitivity, or revenue. More risk datapoint will enable more flexibility and granularity, especially in environments with large numbers of applications. Ways of increasing the maturity of this activity would include adding additional risk factors tied to basic threat surface analysis, such as exposure to the Internet or ability for users to self-register. These factors will provide more insight into the overall risk profile of each application, which can prove useful when trying to focus. XXXXXXXXXXXXXXXXXXX

Basic assessment of the application risk Understand the risk for all applications in the organization Periodically review application risk profiles

Threat Modeling Best effort ad-hoc threat modeling Standardized threat modeling Improve quality by automated analysis

Security Requirements

This practice focuses on the need for organizations to get more explicit and prescriptive with how they define secure software. Relying solely on security scans to identify security exceptions is not feasible and significantly increases the cost of application security. After all, it’s a lot less expensive to write more secure code than to have to come back weeks or months later to find and design a fix. To help organizations gradually implement a security requirements culture, SAMM suggest the following maturity objectives:

• Maturity 1 - Consider security explicitly during the software requirements process.
• Maturity 2 - Increase granularity of security requirements derived from business logic and known risks.
• Maturity 3 - Mandate security requirements process for all software projects and third-party dependencies.

In order to ensure security requirements cover in-house and outsourced development, the following two activity streams should be considered as part of the overall program:

Software Requirements

Organization should begin by publishing relatively high-level security requirements. Initially, the goal should be to make all developers aware of the need to adhere to secure coding principles, and ensure there are sufficient resources to help develop more information when needed. As with many other application security initiatives, this should be done with cooperation and support of application architects to help ensure requirements are applicable and consistent with other architectural standards. Future maturity levels may include substantially more prescriptive requirements and requirements libraries, with applicability determined by different risk factors (exposure to untrusted networks), technologies (many frameworks have specific security needs), and compliance requirements (PCI, HIPAA, Etc.).

Supplier Security

Those companies that do not outsource application development may safely skip this activity. However, those organizations that leverage 3rd parties for software development should ensure these vendors are periodically evaluated to ensure acceptable security practices. Since majority of the biggest breaches have been historically caused by a vendor, this activity should not be overlooked. More mature practices will ensure application security is addressed during the contracting phase and include specific requirements making the development consistent with the in-house development practices.

Security Architecture

Maturity 1 - Insert consideration of proactive security guidance into the software design process. Maturity 2 - Direct the software design process toward known secure services and secure-by-default designs. Maturity 3 - Formally control the software design process and validate utilization of secure components.

Architecture Design Use basic security principles Establish common design patterns and security solutions Create Reference Architectures

Technology Management Elicit technologies, frameworks and integrations within the overall solution Standardize technologies and frameworks to be used throughout the different applications Impose the use of standard technologies on all software development.

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.