Compliance can often get a little side eye from security practitioners. External compliance frameworks are great when it comes to standardizing on customer assurance proof, and regulatory compliance is… well, regulation driven. But, it can sometimes feel like we’re doing significant work for compliance purposes without the most optimal reduction of risk from a security standpoint.
Simplistically, I present to you the following Venn diagram:
A couple of observations:
- Obviously, compliance is not the same as security. There is a sweet spot of perfect overlap where what we must do to be compliant also reduces risk or achieves the security outcome, but it’s not 1:1.
- We have to do some things, from a compliance standpoint, that “check the compliance box” but arguably don’t meaningfully improve our security posture. I’m not saying this is bad. These compliance or regulatory driven requirements matter to someone in your business. It’s a priority. It needs to be addressed. But realize that these requirements may not draw a lot of attention from security teams as they don’t marry up to what is perceived as commensurate risk reduction for the effort. These tend to get minimal effort.
- We have to do a lot of things to be truly secure. And many times, those fall outside of what we need to do, strictly speaking, to meet external compliance / regulatory controls.
In companies where security is paramount (think b2b SaaS, infrastructure, financial systems, and so forth), security is generally responsible for operationalizing a large portion of these governance controls. Furthermore, security teams are looking more and more like engineering teams in terms of how they solve problems.
They have dedicated security engineers focused on automation. They focus on prevention over detection and remediation. They build custom tooling wherever they can to solve repeatable problems. They’re getting out of the business of manual processes and instead are focusing on risk reduction through automation. And, they’re applying the same approaches to governance. These teams are automating user provisioning and application management through Terraform and Pulumi. They’re extracting data for UARs through custom scripts. They’re alerting on high risk access changes through their SIEM and/or slack notifications. And so on.
This is a powerful trend. What’s happening is:
→ Security is responsible for governance & compliance
→ Security is focused on automation and problem solving using engineer-centric tooling
→ Security is automating compliance and extending these controls to improve the organization’s security posture
For example:
- User access reviews (UAR’s) are a powerful risk reduction tool, typically mandated by several compliance frameworks, that are useful for reviewing and removing unnecessary access. Before automation, teams would run these quarterly to semi-annually to achieve combined security and compliance outcomes. UAR automation enables security teams to move to just-in-time reviews, for example: upon a role change, when justification for access changes, when a user is deactivated or more frequently for user types that roll off frequently e.g. contractors. This is unachievable without automation as the effort to drive the process is too high relative to the risk.
- With visibility of access across your environment, you can drive real-time alerting when critical access is granted, when separation of duty (SOD) violations occur, or when any other identity centric security risk is detected (e.g. local or orphaned account creation). The riskiest alerts can be provided directly to where the security teams are already working, namely Slack. Again, this is only achievable through automation and real-time visibility – and not practical if only being executed on a semi-yearly basis.
- You can drive access controls via infrastructure automation tools such as Terraform or Pulumi. These tools are many times being used as a layer to apply policy to apps and infrastructure from an identity and access standpoint. We see many companies depending on infrastructure automation tooling as the enforcement mechanism for who has access to sensitive apps and how access is granted. Source code management software, in turn, becomes the policy definition store and has useful primitives to support its function. Namely, there’s an inspectable audit history of all changes, webhooks, and notifications for changes, and change management approvals.
These are just a handful of examples of identity governance-centric controls being driven from a security automation perspective. At ConductorOne, that’s what we call security-led governance. It’s the automation of traditional governance and compliance controls to a near real-time basis to reduce an organization’s risk posture.
We’re excited to help companies move beyond group membership reviews in the identity provider on a semi-annual basis to check the box on their compliance and governance controls. If you’re excited about achieving better identity security outcomes, we’d love to talk. Send us a note!
