Applying DevOps to GRC
Resilience is more important than happiness. Happiness and satisfaction are second order effects, building resilience increases your chances of experiencing happiness much more than pursuing happiness directly.
Resilience and safety come from humans, not from rules. Technology needs to be molded and shaped to serve humans and reduce toil, rather than humans toiling to feed the machine.
These ideas drive the Kindly Ops GRC framework, which applies DevOps principles to Governance, Risk, and Compliance. Cybersecurity is a popular topic, and it’s a topic too big to fit into any single humans brain. The model enables making sense, navigating this complicated subject.
The biggest idea to remember is there are two things you need to worry about:
1. Doing a good job 2. Getting credit for your work
Lets dive into the model.
Phase 1: Build Empathy
It’s common to see frustration and resentment when working with a team that has been busy inventing new products and now has to meet regulatory compliance standards. The same frustration occurs in a team that has a long history of dealing with compliance, and is getting pressure to move faster and take more calculated risks.
Rather than criticize people for feeling frustrated, step one is to help build empathy for other points of view. The most helpful tool we’ve found is the Security Culture Diagnostic, created by Dr. Lance Hayden and released under a Creative Commons License.
One useful definition of Culture is the beliefs and assumptions that drive decisions and behavior. Another term for beliefs and assumptions that drive decisions and behavior is a mental model. While we may have a preferred or default mental model, we are all capable of considering and using alternative models. SCDS presents 4 common mental models, helps you identify your default, and makes you aware of other mental models or world views and when they have value. I’ll go into SCDS in more detail in a future article.
Phase 2: Set a Baseline
Agreeing on a regulatory framework and/or controls baseline is a crucial step for orienting everyone around a common set of objectives. It’s also the fastest way for folks to get credit for the good work they are doing and the good practices that are already in place.
There are several different types of frameworks.
First are industry standards that have formal audits and certifications performed by accredited firms. The most familiar are probably the SOC 2 report and PCI-DSS. These tend to be more generic, and you get a very clear pass/don’t pass when an audit is performed.
Second are sets of laws that form regulatory context, but are less prescriptive and require considerable effort to interpret for your specific sitation. Examples here are HIPAA and GDPR.
The third and most useful category for folks just getting started are a prioritized set of controls that are useful building blocks toward any of the previous schemes. The most useful are published by the Center for Internet Security, called the Top 20 Critical Security Controls.
Phase 3: Risk Analysis
The baseline sets a bar based on good industry practices. The baseline is necessary but not sufficient for doing a good job. Industry good practices are sort of a lowest common denominator. Risk analysis focuses on the risks that are unique to your organization. Some of the controls you have put in place for the baseline may reduce the risks you face, but the scenario-specific analysis will identify areas where you need to do further work specific to your organization.
The most common way of doing risk analysis is qualitative. You’ve probably seen these heatmap charts with high/medium/low risks, and high/medium/low impact.
There is a much better approach to risk analysis that improves results and makes the results more useful for decision making. This is quantitative risk analysis, and we’ll dig more deeply into a popular method called OpenFAIR in a future article.
Phase 4: Continuous Improvement
Maturity models, baselines, and risk analysis help an organization make initial improvements. However, the world continues to change around you, and so do the people in your organization.
A useful way to monitor continuous improvement in your organization is the FORCE metrics, also created by Dr. Lance Hayden. These 25 metrics help you understand whether your organization is improving along 5 domains.
- The security value of Failure
- The security value of Operations
- The security value of Resilience
- The security value of Complexity
- The security value of Expertise
One of the next articles will dive more deeply into the FORCE metrics and experiential learning.
Thats the model! Next time I’m going to take a closer look at phase 1, building empathy. If you made it this far, hit reply and let me know what you think 😊