DevOps and IT Governance Work Better Together

IT governance is not cloud governance.

Every company that ventures into the cloud ultimately crosses into the blurred world of governance. IT governance encompasses a range of functions and knowledge and, in its own right, takes skill to balance needs versus productivity. With the addition of cloud technologies, organizations can expect plenty more knobs and dials that, in the end, form a complex attack surface if implemented incorrectly.

Discover how CDW can assist you with your DevOps and IT governance needs.

A traditional IT governance team or role helps the organization focus on managing risk, balancing compliance frameworks and managing an ever-growing list of standards and controls, knowing that there isn’t a one-size-fits-all approach to IT governance. An oversimplified list might include password management, data classification policies, PCI controls and an understanding of business needs to achieve performance. The need to manage compliance can include a dizzying number of items to examine. No one team can do everything, so building in the teamwork of a DevOps-driven culture is key to using and ingesting technologies that come in at an ever-increasing pace.

Cloud governance can be looked at through the lens of resource limits, creating policies, tagging, reporting and visibility around consumption. These tasks are important for cloud environments to function efficiently and safely. No one wants a surprise from a billing or security perspective, so we put a lot of faith in “proper implementation” of applications and systems. One wrong move and suddenly you’ve got problems with data exposure, openings into your business via other ingress paths, or missed data classification where business units might have a differing opinion of what’s appropriate.

Let’s highlight an example of the danger of terminology overload with the term “governance.” If we ask a customer if they are doing governance and they respond, “Yes, we are doing cloud governance,” we can’t tell what that customer means by the use of “governance.” As IT coworkers, we are not doing ourselves any favors by enabling an opaque response like this. We are using the term “governance” for what’s really “applying policy guardrails,” but that’s just the tip of the iceberg when it comes to true governance. We participate in a mental trap, which creates ambiguity on what “governance” means, and it’s the last thing we want to be ambiguous about.

Audit vs. Applied Security

Strategies for managing IT governance with cloud governance can come from two different angles: Enabling IT governance to focus on auditing that security controls are in place, or being the people applying security. Organizations deploy a mix, but it’s not usually a conscious decision. Instead, this evolves organically and they do themselves no favors by not being deliberate in their path.

If IT governance is focused more on auditing, then there are a few key goals:

1. Continuous attestation: Software, processes and education that enable an accurate record of activities, settings and sign-off that controls driven by IT governance are adhered to.

Questions you can use to measure accuracy:

• Did we add any new pipelines or systems that need to confirm that IT governance mandatory controls have been implemented?
• Are we able to view the whole domain of our IT footprint to see if we have any systems that might trigger a brief review?

2. Catalogs of approved settings and services: Build collections of pre-approved uses, configurations or services, making use of the approved structures easily and quickly. DevOps is about experimentation and agility: The more you can expand or improve the catalog of what is available, the more likely you are to incentivize desired behaviors.

Questions you can use to measure accuracy:

• Are we seeing exceptions coming in requiring additions to the catalog of available default policies or profiles?
• Can we measure how often we’re reusing existing catalogs of available default policies?
• Are we able to track changes to our acceptable use of cataloged items?

If IT governance is focused more on applying controls, then there are a few key goals:

1. Select tooling appropriate for today’s world: You might need to look at new tooling. There is no shortage of security tools, and they’ve traditionally never been cheap. If you have legacy tooling, look to jettison tools that are not API-driven so you can work to get them integrated with code.

Questions you can use to measure your capability:

• Can our security tools scale with the use of cloud?
• Are we currently applying our security tools deployed in a pre-cloud model mindset and thus are not adapting?
• Do our tools have the capability to be delegated to be used directly by developers and operations?

2. Be clear about how the tooling applies to manage controls: Users and consumers of tools do best when there’s no tribal knowledge, and coworkers need to understand how use and misuse affect the organization. Tools and controls integration can be quickly undone if the people who know about tooling are limited or hard to work with.

Questions you can use to measure your capability can include the following:

• Do you have examples or reference architectures?
• If you survey your teams, do they get what the tools are for?

Enable, Share and Eliminate Silos

Since security is everyone’s job, compliance is about the reasonable translation of efforts. No one person is going to track every requirement off the top of their head, let alone all of the different controls that could be enacted. Just like DevOps means enablement of a culture, we have start setting up the structure to enable others to help carry out the full mission.

For example, if your organization is working via CICD pipelines, IT governance might require steps around continuous attestation in every pipeline. IT governance is going to audit pipelines to confirm they all have controls, but DevOps is going to be aware of the integrations that have to be there. IT governance is going to reinforce how coworkers in a DevOps organization can find the resources so they can help fulfill the mission. Workers who can find consumable patterns or reference implementations can digest the implementation, so they don’t just have instructions but see the impact as well.

Seeing the impact reinforces the need, shows the context and gives the ability to contextualize other security controls that might be implemented. Processes like continuous attestation make sense because the instrumentation points are visible, intermingled in constructs like a CICD pipeline. If the security tools are integrated in at key control points, then the injected tooling can help with managing compliance list items.

With each new construct that is deployed, questions around data classification, controls, reachability, cost and others come under the scrutiny of IT governance. These questions also help determine what are reinforceable behaviors. A healthy DevOps culture is enabled, can experiment and has room to grow to help eliminate tribal knowledge. Not everyone is going to understand the whole swath of controls, but you are building a distributed culture, and enabling it can be empowering and time saving.