How A Balanced Development Security Fabric Enables Business Agility

In a world where business is moving faster than ever before, security teams have a vital role to play in supporting this strategic trend across industries. A key initiative that security teams can help with is the creation of a balanced development security fabric that brings security, risk and compliance to DevSecOps delivery pipelines natively, instead of adding them after the fact.

This fabric integrates disparate pieces of security data strewn across product delivery pipelines and tools. Only by stitching this data together into an integrated fabric that achieves the right balance can they hope to achieve the speed to market demanded by businesses.

Defining Business Agility

There is a lot of talk around business agility. What does this mean? There are three areas to consider here:

• Traceability: This implies the ability to drill down and provide a reasonable defense for the security metrics and recommendations being made.

• Integration: Involves gathering and sharing data across multiple systems to provide a more comprehensive view rather than from a single tool.

• Automation: Automation implies the removal of human intervention as much as possible.

All three of these attributes must be in play for security teams to help their respective business teams. Without traceability, the integrity of the security discussion is weak. If integration is not achieved, the argument for security is weakened if additional data is produced. From an automation standpoint, it is essential to produce security data in a timely, repeatable manner. The collective benefit of these attributes is to provide meaningful and relevant information to business teams so they can make informed decisions about speed to market.

The Challenge Before Us

We have two key challenges facing us as a security community today:

• Our security artifacts are not integrated: We use different tools that are not well integrated with DevSecOps tools. These tools produce different reports, contexts and metrics. Aggregation of this information is often manual and hard to repeat and scale.

• Our security processes are not integrated: Business and product delivery teams operate in silos. The business architecture itself does not support the integration of security and DevSecOps teams. This fights against the notion of simplifying in order to increase agility.

The good news is there is considerable work being done in the industry to help resolve these issues. For example, the Open Group’s IT4IT community and Linux Foundation’s OpenSSF initiatives are actively trying to solve these problems.

Next Steps

There are key principles security teams can embrace to address these challenges:

• Think platform orchestration instead of tool execution: Security tools need to be integrated. Security teams have to aggregate the data at a semantic level that has business context. They need to automate the orchestration. This can be achieved by creating a platform that sits on top of DevSecOps tools and could be used to trigger activities in various DevSecOps tools and gather resulting data from those tools. The team could then turn the aggregated data into business metrics around security and risk which, in turn, would inform the business in near real-time.

• Develop a knowledge base: The security team should compile information around coding best practices to aid developers in situ. This information is correlated with policy management capabilities for security and risk policies related to product delivery. The team can then integrate the information and policies with technical architecture. All three of these aspects need to be integrated to form a powerful knowledge base. This can be achieved by a knowledge management graph that maps coding practices, policies and technical architecture. The resulting knowledge base can be queried by different stakeholders.

• Focus on specific security use cases: Rather than trying to build every security use case, consider how threat modeling, code scanning and functional testing artifacts can be reused across the product delivery lifecycle. The focus is on reusability across the lifecycle rather than immediate delivery in a specific phase. This can be done by focusing on areas within DevSecOps with acute pain around slowing down the business and where a high degree of automation is possible. Leverage existing databases such as MITRE CWE and OWASP Top 10 to limit rework.

• Speak the language of the business: Key issues from a business perspective are related to resiliency, revenue and risk. The goal is to integrate the various tools and the data from these tools into buckets that make sense for your business. This can be achieved by understanding what is most important to your business for time to market. Then translate those requirements into DevSecOps pipeline metrics that can be gathered easily through automation.

Security Should Enable The Business

There is a tremendous opportunity for security teams to play a vital role in helping their respective business improve its agility and achieve speed to market for product delivery. For a long time, security has been perceived as a blocker with a long list of security controls. While I am not advocating the removal of controls, I believe the security community needs to find ways to embed these controls proactively into delivery pipelines as a means of achieving quality at speed.

The paradigm for security has shifted to become a critical capability across the organization, and the challenge is leveraging this competency widely through automation, education and traceability.