What is Automated Governance?

Automated Governance brings the same speed and quality assurance of DevOps to information security, audit compliance, and change management. After all, when developers are pushing changes to production every few minutes, no manual governance model can keep up, which leads to workarounds and shortcuts, which leads to vulnerabilities and non-compliance. To relieve this bottleneck, we must seek to automate the governance processes, which is the subject behind the new book Investments Unlimited. 

In much the same way that The Phoenix Project helped illustrate through story what DevOps could bring to the enterprise, Investments Unlimited seeks to do for Automated Governance. This post provides a primer for readers looking to understand Automated Governance and how it will help speed time to value without sacrificing quality, security, or compliance. Plus, like DevOps, it will improve the lives of auditors and InfoSec professionals in the enterprise.  

How We Got Here

The DevOps revolution of the past decade brought the functions of software developers and information operations together to negotiate their individual interests for the collective interest of their organization. In other words, instead of acting as two silos on different sides of a brick wall, they came together as a single cohesive team. 

Thanks to these DevOps practices, IT delivered software and business value to market with greater speed, greater employee happiness, and higher quality. But the functions of security, audit compliance, and change management were left out, remaining on the other side of the proverbial brick wall.

While DevOps advocated for shifting left on these functions (bringing them in earlier in the software delivery cycle), many enterprise organizations have struggled to modernize what has traditionally been a slow, manual process. And many still mistakenly believe that automating governance will create more risk and vulnerabilities. But history has shown that this is far from the truth

Manual models of governance favor the interests of a few over the collective interests of the organization. Automated Governance, on the other hand, provides the paved road for compliance and security, making the right path the easy path and further aligning the different roles within the enterprise to help bring business value to market sooner, safer, and happier (as Jon Smart would say). 

How Automated Governance Works

Automated Governance is at its best when it is part of a continuous integration and continuous deployment (CI/CD) capability. In this model, there are no human hands (no manual hand-offs) from commit to production. Thus, security, compliance, and audit needs are met 100% for every commit. With Automated Governance, there are no workarounds or shortcuts that inadvertently lead to risk and vulnerabilities.

Think of a governance validation much like a behavioral-driven test scenario. Security, compliance, and governance are simply another form of functional validation in today’s world.

As with all automation, speed does not come primarily from the act of automation. Speed to production is a positive byproduct of reduced variability provided by automation. Making sure the same thing is done the same way every time reduces slow-downs caused by situations where employees have to “dig deeper” to understand why “something so simple” has gone awry. 

Automated Governance Reference Architecture

The DevOps Automated Governance Reference Architecture (DAG) is the framework for bringing Developers, Operations, Security, Compliance, and Audit to the same table. The DAG is key to negotiating the collective interests of the organization over the individual interests of any specific group.

In 2019, a group at the DevOps Enterprise Forum came together to discuss and provide guidance on how to implement a DevOps Automated Governance and Reference Architecture process in an enterprise environment.

Our initial focus was to design a model flexible enough that it could easily be extended and adopted by organizations struggling to maintain compliance and audit controls as their software delivery speed increased. We wanted to create a reference architecture that enables an organization to create trust within the process of delivering software and services. As organizations further automate the continuous delivery of software and services, they also need to ensure there are common validations and trust mechanisms throughout the process. Ultimately, a DevOps automated governance process can assure organizations that the delivery of their software and services is trusted.

The DAG allows you to define any process for your software development life cycle from end to end. It specifically emphasizes the inclusion of others outside of development and operations.

The DAGs focus on generating your IORCAAs (Inputs, Outputs, Risks, Controls, Actors, Actions) for each step of the software development life cycle. Each of these is defined as follows:

• Input: The “things” (source code, artifacts, etc.) required for a process step to operate.
• Outputs: The byproducts expected as an outcome of the processing of the step.
• Risk: Potential risks that need to be mitigated as part of the processing at the step.
• Controls: The specific policy controls which need to be addressed at this stage.
• Actors: All persons required to process the step
• Action: The specific type of processing that turns the input into output and evaluates the input, or output, for comparison to some expectation.

Automated Governance Tools

Many tools have emerged to address pieces of the governance process. There is no specific tool to automate your governance process. This is not a question of build vs. buy, it’s a question of what to build and buy. 

You’ll generally procure tooling that scans software artifacts for specific reasons, such as vulnerabilities and dynamic or static code analysis.  

While scans are an important action of the Automated Governance process, they are not the end-all-be-all. These scans produce critical evidence for the governance process, but they must also be applied as attestations to tie the evidence of meeting the control to the control itself.

Some examples of attestations collected from controls include statements such as:

• Control: Unit tests
  • Attestation: “All tests executed and passed.”
• Control: Clean dependencies
  • Attestation: “All dependencies in this build satisfy local licensing policies.”
• Control: Clean dependencies
  • Attestation: “All dependencies in this build are free of known security defects.”

A single control may record more than one attestation. These attestations begin as ordinary tool outputs but need to be collected so that auditors can later verify the origin and integrity of the attestation. (An example of a mechanism to collect such attestations is the open-source tool Grafeas.)

How Automated Governance Can Help Your Organization

Automating Governance does one thing and one thing very well. It ensures the expectations of your governance process are met without impunity. It positively structures your governance approach to leverage the strengths of your organization while negating the human elements that negatively affect governance outcomes 

Relying on humans to execute the governance process is where impunity enters the equation. Humans are not consistent by nature. Give the same evidence and controls to two different auditors and place bets on if they both come back with the same answer. As you know, they likely will not.

Many factors impede a person’s ability to apply judgment consistently. Any type of bias will sway that judgment. Shai, Jonathan, and Liroa demonstrated how judges within a legal system provide more strict assessments of their defendants if the court hearing was before lunch instead of after lunch. While this is just one example of many, dig deep into biased research, and you’ll soon discover humans do many things that are counter to what we think we are doing.

Now, you may be thinking that you don’t want humans anywhere near the governance process. Well, we still need us! The place humans operate the best is not in the repetitive execution of the same thing repeatedly. Humans operate the best when given a problem to analyze and explore.  

Re-focusing human effort on the continuous discovery of new and enhanced governance controls is the optimum way for people to contribute to the governance process. 

Humans should explore, understand, and codify the expectations of the governance process. Machines should execute the continual evaluation of software artifacts and systems against the codified expectations humans provide.

Where to Get Started

We can see how, after reading most of this article, one would be confused about where to start. It’s not hard. Of course, we’ll tell you it’s simple. You are simply flexing that DevOps muscle for a new exercise.

First, start simple with a single application or software system. The target application should not be overly complex and not overly simple. You must select one that requires you to get a representative from Development, Operations, Security, Compliance, and Audit into the same room.

Second, select a process step to create an IORCAA (Inputs, Outputs, Risks, Controls, Actors, Actions). Starting with the first step of the process is possibly the best place to start. In general, this may be simply automating the validation that at least two people, one of them not being the person who commits a change, have provided an approval or review of a change.

Use this step to build your organizational muscle for developing an IORCAA. Don’t be fooled. This is the most critical step. The organization also uses a not-so-flexed muscle: the ability to negotiate the collective interest over the individual interest.

It’s best to staff this first trial with people who want to make this work. Be leery of simply leveling this as a Business Goal and Objective for a random team to accomplish. The people who have the innate willingness to set aside their differences to explore automating governance in your organization are worth their weight in gold. Their outcomes will be highly focused on either the single way or the multitude of ways your organization can automate governance and not the litany of why-not reasons.

Third, automate the IORCCA. Support a set-based concurrent engineering approach to the development of the automation. It’s key to remember that any specific automation implementation is not the goal. Rather, it’s the automation implementation that yields the best long-term probability of support within the organization. Your objective is to automate this one IORCCA.  

Time-box this step and ask for up to 3 or 5 implementation approaches from the team. Then, have the team discuss the merits of each implementation option. There is no need to overanalyze at this point. Simply pick the best one given the information you have and move forward. 

Once you have decided, make sure not to completely disregard the options that were not selected. Store them safely. As you add design implementations for other IORCAAs, the lessons you learned with these set-aside implementations may be useful as implementation details for those other IORCAAS.

Fourth, rinse and repeat. With the same team, continue to iterate one IORCAA at a time until the team believes the full governance process has been automated for that single application. It’s very important to keep the focus on this single application. If you start to broaden the effort at this early stage, the team will experience the burden of extensive communication overhead.

Make sure to balance the need to learn with the need to communicate change. If you attempt to roll out changes too early, your landmark team may get completely caught up in the change management effort. This will distract them from completing a full end-to-end example. Without this end-to-end example and the lessons learned, all future efforts will devolve into a series of partial implementations or abandoned efforts.

Finally, select the second application. With the second application, select a new team but don’t eliminate your original team. Now, you have a train-the-trainer scenario. The first team’s focus shifts from exploring how to implement the automated governance process to explore how to communicate and teach what they learned. When this is done well, you’ll have set the organization not just on a pathway to automating governance, you will have established the basis for automated governance as an internal product team.

- About The Authors

Bill Bensing

Bill Bensing tranforms Shadow IT into legitimate software development organizations. Bill's recent thought-leadership is proving software devliery velocity and highly secure and compliant software are not mutally exclusive. He lives in Tampa Bay, FL, area.

Follow Bill on Social Media

• 
•