Strategy & Metrics (BSIMM6 Part 2)
“There is nothing so useless as doing efficiently that which should not be done at all.” – Peter F. Drucker
The Strategy & Metrics practice is the first practice of the BSIMM6 Governance domain. It describes activities such as obtaining executive support, defining a security process, raising software security awareness, identifying and enforcing strategic security gates within the existing software development life-cycle and collecting metrics that help to create situational awareness and drive budget. More information about the Strategy & Metrics practice can be found here. The full BSIMM6 is available under the creative commons and can be downloaded at https://www.bsimm.com/download/.
Practice: Strategy & Metrics
The governance domain contains practices that help organize, manage, and measure a software security initiative. Strategy & Metrics, the first of three practices in the governance domain addresses planning, assigning roles and responsibilities as well as identifying metrics and gates.
In the first part of this blog series it was established that BSIMM6 activities are categorized in maturity levels ranging from low maturity (level 1) to high maturity (level 3). This article focuses on the foundational activities (maturity level 1), however if you want to learn more about the activities in maturity level 2 and 3 visit the strategy & metrics section at the official BSIMM6 website.
Software Security Initiatives have little to no chance of success without full support from senior executives in an organization. By demonstrating the negative business impact of inadequate software security, executives will come to support the initiative as a risk management necessity. Once executive and board support has been acquired, the software security initiative can be properly planned, budgeted and executed.
One of the most well-known instances of how executive support has helped start an immensely successful software security initiative is Bill Gates's memo on Trustworthy Computing from January 2002.
Create and publish process
In that infamous memo, Bill Gates also states: "Security models should be easy for developers to understand and build into their applications".
In order to consistently address software security on an organizational level a clear process has to be defined. This process describes how security is addressed end-to-end in all phases of the development life-cycle. It also defines key roles and their responsibilities within that life-cycle. In most cases organizations look at already existing and proven processes and adapt them to their needs.
A high level overview of the phases that the Microsoft Secure Development Life-cycle consists of is shown below.
Source: Microsoft SDL
It is important to understand that the secure development life-cycle defines activities and gates in the existing software development life-cycle. It has to be applicable to all practiced development approaches such as Waterfall and Agile, although the implementation strategies typically vary.
Create evangelism role and perform internal marketing
After publishing the software security process, the next step is to create an evangelism role that raises the awareness of software security in the organization. This can be done through regular internal events that promote the use of the software security development life-cycle. At Microsoft, Michael Howard took over the evangelist role just after the Gates memo.
Identify gate locations, gather necessary artifacts
Out of all activities in this Security & Metrics practice, this one has been observed in most organizations.
If you are not doing this activity yet, then it is a good place to start.
The first two steps toward establishing security-specific release gates are:
- Identification of gate locations that are compatible with the existing software development life-cycle.
- Gathering of artefacts necessary for making a go/no-go decision.
At this maturity level gates are not enforced but the artefacts are collected nonetheless. The benefit of this approach is that it serves to motivate good behavior without requiring it, as opposed to introducing security stop gates early on that could result in poor adoption of the software security initiative.
Start. Stop. Continue.
Consider the following strategy:
- Start: Identifying strategic gate locations in the development life-cycle and collecting security relevant artifacts.
- Stop: Addressing software security without clearly defined touchpoints in the development life-cycle.
- Continue: Educating executives about the business impact of poor software security and garnering their support.
How does your software security initiative compare with your industry peers? Contact us to find out.