The goal of an SSI is to improve security at every stage of the journey. Start and/or improve your SSIs today with these key steps observed in BSIMM11.

If you care about software security—and you should, since to be in business today means that no matter what you do or produce, you’re also a software company—you should be interested in the Building Security In Maturity Model (BSIMM). It can serve as a roadmap to better security.

The focus of the BSIMM, an annual report now in its 11^th iteration, is software security initiatives (SSIs), a combination of standards, policies, and metrics structured to fit the individual needs of an organization and its staff, processes, and software portfolio. The goal of an SSI is to improve the security of every stage of the software journey—designing it, building it, and maintaining it.

The evolution of the BSIMM

Since 2008, the BSIMM team has tracked SSIs in 211 organizations in multiple verticals. This year’s report is based on detailed observations of 130 participating companies, primarily in nine verticals and spanning multiple geographies.

You can download the entire report— it has always been free and open under the Creative Commons Attribution-ShareAlike 3.0 license.

But this post focuses on the ways BSIMM11 can guide organizations in starting or improving an SSI.

The BSIMM does not prescribe a set way to do things. Instead it observes and reports on software security activities—where organizations are actually spending time and money. The report has been described as both a measuring stick and a roadmap, not an instruction manual. But its observations outline five steps that can help organizations start and/or improve their SSIs.

1. Identify your SSI phase

Regardless of industry or specific practices, there are three phases through which organizations implementing SSIs typically progress.

Emerging

This refers to an organization starting from scratch or formalizing ad hoc security activities. This phase involves defining an initial strategy, implementing some foundational activities, and developing a rough roadmap. The obstacles of this phase generally include a lack of budget, resources, and talent. It takes an average of 12-24 months to get through this phase.

Maturing

This refers to an organization with an existing or emerging SSI and that is working on scaling, streamlining, and meeting executive expectations. This phase can include applying existing activities to a greater percent of technology stacks, departments, or the software portfolio. Also, the SSI leadership might reduce the number of activities while increasing the depth, breadth, and cost-effectiveness of current activities.

Optimizing

This refers to an organization at a level where it can fine-tune its existing SSIs. During this phase, SSI management has a clear view into operational expectations and associated metrics, it can adapt seamlessly to technology change-drivers, and risk management and business value are clearly demonstrated as differentiators. Also, the SSI leader may shift from a technology executive to a business enabler.

All organizations should progress from one phase to the next, but since they’re all different, they don’t all necessarily progress in a straight line. Certain practices or activities may lag or leap far ahead of others during the development of an SSI. Some organizations repeat a particular cycle some number of times before they mature to the next phase. Given the complexity and variance between each SSI and its people, practices, tools, and skillsets, these phases are just rough indicators of progress. After all, a roadmap doesn’t force everyone to take the same route to a destination.

Each organization should review the common markers found in each phase and assess which phase reflects its current SSI maturity. That will make it easier to determine which activities in BSIMM11 are best for its SSI phase of maturity.

2. Embrace and implement DevOps activities

Over the past decade, the BSIMM has found that companies usually select one of two cultures for the management and development of their SSIs—one formed and managed under a central corporate group, and the other managed under engineering leadership. The first model focuses mainly on compliance, risk management, and testing. The second emphasizes security standards, development processes, and cooperation across teams.

But in both, the SSIs are driven by the same centralized and dedicated software security group (SSG). The BSIMM doesn’t highlight which culture is best for an SSI but rather focuses on the need for an SSG to be responsive and proactive about bridging gaps between departments and normalizing activities across disparate teams.

Engineering leads software security efforts

Indeed, the need for cooperation and collaboration among teams that used to function separately is even more important in a development environment that has moved toward DevOps, where practices, tools, and activities are all focused on delivering at high speed and high quality.

BSIMM11 found that engineering teams were initiating software security efforts themselves, primarily because of two factors:

• Friction, in the form of corporate process disruption, disturbed delivery schedules, troubled interpersonal relationships across departments, and the increase in human-intensive processes. All of those slow development down.
• Agile and DevOps delivery practices require involvement at the engineering level. Also, there’s more to security in DevOps than what is covered by just the tools/processes from corporate.

BSIMM11 also notes the move toward DevSecOps, where security is “baked in” to all aspects of the DevOps development life cycle, thereby bolstering development, increasing velocity, reducing friction, and strengthening collaboration.

These findings illustrate the need for SSIs that consider engineering self-service, automation in the development life cycle, and the removal of friction points.

DevOps culture is critical to SSI development

When formulating your own SSI strategies and practices, it is crucial to include DevOps culture into activities and considerations. Automation—in particular software-defined sensors and checkpoints—is creating consistency and bypassing unnecessary human involvement that can slow the process down.

But don’t let the need for speed eliminate adequate consideration for security. Security practices and tools that can keep up with the speed of DevOps are critical.

3. Consider these key activities for your new SSI

Activities are the central focus of the BSIMM; their prevalence or disappearance within industries point to trends, what works, and what doesn’t. Activities are security controls carried out or facilitated by the SSG as part of a specific practice.

This year’s report found explosive growth in several activities that were recently added to the BSIMM, which points to their widespread utility and possibly their effectiveness or critical role in current-state SSIs. You should examine these activities, listed below along with a brief description, to determine if they are applicable to your SSI, and if so, whether they can be improved or implemented.

• SE (software environment) 3.5 Use orchestration for containers and virtualized environments

The organization uses automation to scale service, container, and virtualized environments in a disciplined way. Orchestration processes take advantage of built-in and add-on security features, such as hardening against drift, secrets management, and rollbacks to ensure each deployed workload meets predetermined security requirements.

• SE2.6 Ensure cloud security basics

Organizations should already be ensuring that their host and network security basics are in place, but they must also ensure that basic requirements are met in cloud environments. As BSIMM11 puts it, “cloud providers are 100% responsible for providing security software for organizations to use, but the organizations are 100% responsible for software security.”

• SE3.6 Enhance application inventory with an operations bill of materials

You can’t protect what you don’t know you have. So a list of applications and their locations in production environments is essential for any well-run enterprise. Also, a manifest detailing the components, dependencies, configurations, external services, and so on for all production software helps the organization tighten its security. That also helps it react with agility as attackers and attacks evolve, compliance requirements change, and the number of items to patch grows.

• CMVM (configuration management and vulnerability management) 3.5 Automate verification of operational infrastructure security

The SSG works with engineering teams to facilitate a controlled self-service process that replaces some traditional IT efforts such as application and infrastructure deployment, and includes verification of security properties (e.g., adherence to agreed-upon security hardening). Engineers now create networks, containers, and machine instances; orchestrate deployments; and perform other tasks that were once IT’s sole responsibility.

4. Ensure your SSI includes these critical activities

No matter the phase of your organization’s SSI, BSIMM11 findings document the most common activities in each of the 12 practices. Although these activities may not be essential to every SSI, they were observed in the majority of highly successful initiatives, pointing to their importance.

5. Implement these steps to jumpstart your SSI

As noted earlier, there are two paths or cultures for SSIs: corporate-led and engineering-led. The BSIMM has “getting started” recommendations for each path. When you get your free copy of the BSIMM, start by identifying which one best aligns with your SSI, and then review the appropriate checklist.