Enabling Governance in DevOps: the myth of security as a disruptor

Enabling Governance in DevOps: the myth of security as a disruptor

Businesses today have enormous sets of policies to comply with and no way to translate those policies to their operations. The problem is that there is a vague sense of compliance and operations, without any guidance that leads from one to the other. This is the policy-to-execution gap. How do we streamline the process of turning policies into actionable tasks?

The importance of governance 

The answer lies in governance. Most organizations are already implementing risk management and compliance. Risk management is made up of all of the activities an organization completes in order to assess risk, identify industry regulations to comply with, and define security policies. Compliance operations are then completed by IT teams to execute these policies. However, in the middle of all of these procedures is the gap created by ignoring governance.

Governance designates the people, processes, and controls that allow an organization to achieve its goals within appropriate boundaries. Where risk management results in security policies, and compliance results in operations, governance is the missing piece of the policy-to-execution puzzle. It provides the framework from which risk and compliance can cascade seamlessly toward actionable procedure.

The myth of security as a disruptor

Underscoring this challenge is the misconception that security is a force of disruption. The modern development cycle is continuous and vigorous because no organization can afford to move any slower. The quickened pace of development and the increased frequency of release cycles applies pressure to the organization to ensure cybersecurity policies and controls protect its assets and revenues. Shifting left in the development lifecycle, or designing with security in mind, is more effective than trying to retrofit security into the DevOps pipeline after the fact, but why does injecting security into DevOps meet with pushback? The reason is that shift isn’t far enough to the left; security won’t fit into the traditional horizontal DevOps pipeline because it’s already too late. Security needs to conform to the vertical pipeline that exists within the architecture of your organization before it can conform with development.

Figure 1. A traditional example of a horizontal DevOps pipeline.

The vertical pipeline that forms the lattice of your business is where the policy-to-execution gap originates, but this isn’t obvious. In fact, conceiving of business architecture as a means of security instead of only application architecture is not being discussed. The Shift-Left mentality of security has already required a conceptual shift, but that transition extends to the layers of your organization where security does not produce a force of disruption but one of cohesion.

Figure 2. The vertical policy-to-execution pipeline of a typical organization.

The vertical pipeline defines your business, its programs, and its projects. This architecture defines the security controls that need to be implemented, who is responsible for that implementation, and how the implementation is executed. Teasing apart the threads of security controls begins here so that security extends to every layer and the horizontal DevOps pipeline inherits its security-by-design. This is how policies become actionable tasks that support your business rather than disrupt it. So how can an organization begin to create their own policy-to-execution pipeline?

Creating the policy-to-execution pipeline

Traditionally, security policies are defined using existing standards, regulations, and frameworks. These policies manage your organization’s risk and are then executed by operations and IT teams. The gap is filled by governance, which addresses how policies are executed, and what components are involved. Drilling down deeper, governance comprises three essential components—the Who, What, and How. The Who answers the roles required to translate policies to controls; the What defines the controls that must be executed; and the How addresses processes that need to be in place to execute this translation from policy to procedure. This is where organizations will need the most assistance because translating policies to actionable procedures requires a specific set of skills and experience that is scarce in the industry.

Security is not disrupting your organization. Paradigms are shifting, and an organization cannot build a secure development and operations pipeline without first implementing governance holistically. Security begins with the layers of an organization before it can be applied to the phases of DevOps. Governance is the aspect that tends to be overlooked, where instead policies may be hastily transformed into procedures that are implemented at the cost of efficiency and continuity. Attempting to pursue risk management and compliance without governance lends itself to security that disconnects and disrupts. Such an approach is not sustainable, and its correct implementation starts at the level of your business architecture.

This is the conversation that your organization needs to have, and this is how it starts. To read our white paper, ‘The New Reality – A Complex and Constantly Changing Environment,’ visit here.

To learn more about how you can start to bridge the gap between policy and execution, visit here: https://www.securitycompass.com/free-demo/