CISOs to Developers: Changing the Way Organizations Look at Authorization Policy

In today’s cloud-native, app-first and remote-first world, it has become a considerably more complicated task to verify the identity of a user or a service, and determine policies that say what they are and aren’t allowed to do.

Yet, the first half of that problem, authentication, for the most part, is already solved because of standards like Security Assertion Markup Language (SAML), OAuth and Secure Production Identity Framework for Everyone (SPIFFE). These standards help organizations verify that a user or machine is who they say they are. But the second part of the problem, authorization — deciding what users or machines can or can’t do within the system after they’re authenticated — is a different story.

Unlike authentication, authorization hasn’t yet been well standardized. This means that authorization policies, tooling, implementation, and even the programming languages used are still completely unique and custom-designed for each individual organization and application. This puts the burden on developers to create potentially thousands of bespoke authorization policies across multiple applications for protection, leading to development churn and repetitive tasks across applications. Not only is this hard work, requires reinvention and lots of operational overhead, it also introduces risk.

Enterprises have been doing custom authorization for decades now. As such, Dev teams may not realize a better way can be found, leaving CISOs and security teams to try to fill in the gaps with compensating controls in other places, like bolted-on privilege management or overburdened authentication solutions. But these silos of policy add more complexity, not less, and can only do so much to truly govern access.

Imagine if you’re a large financial institution with thousands of applications accessed by tens (or hundreds) of thousands of employees, contractors and other users. The authorization policies that govern access to these applications are varied and complex and they are mandated by both internal and external regulations.

For decades, these policies have been enforced manually or through hard-coded logic inside of application code. The former provides no guarantee that policies are adhered to and requires costly and time-consuming manual audits. The latter results in a tangled mess of code that few can understand or modify. As business requirements evolve, the rollout of necessary changes is slow and error-prone with both approaches and the firm’s competitive advantage is impacted.

At the same time, as every organization slowly becomes a software company, developers have more say in technical decision-making and increasingly opt to use the best language, framework, database or execution environment for their use case. This cambrian explosion of technological choice is great from the developer’s point of view as they get to use the best tool for the job. At the same time, security practitioners are faced with an increasingly difficult technological landscape that must be secured to meet new stringent requirements.

The combination of these factors calls for a new approach to solving policy and authorization at scale in large organizations. The old ways of solving “who can do what” no longer apply.

Authorization can no longer be maintained through tribal knowledge or custom hard-coded application code. Continuing down this path will only leave developers with more siloed authorization policies to fix and your organization unprotected in the cloud. Like authentication, new standards must be set by the enterprise through open source. And CISOs are helping lead that change by adopting and advocating for these standards.  

Open Policy Agent (OPA) has been adopted by the open source and developer community as the de facto standard for authorization. OPA is an open-source technology engine that provides a toolset and framework to unify policy across your cloud native tech stack. With OPA, you can specify policy-as-code, which offloads policy decision-making from your applications, removing the need for custom hard-coded authorization policies. 

There are three critical ways OPA can help organizations solve for authorization:

1. OPA breaks down policy silos. OPA can act as a decision-making engine for all applications in your tech stack thereby unifying authorization policy. OPA uses Rego, a simple declarative language that is purpose-built for expressing the logic that decides “who can do what” in modern systems.

2. OPA ensures compliance. Make it easier for your developers to modify authorization policies based on compliance regulations. By leveraging policy as code, developers don’t need to make individual policy updates across multiple applications. Instead, developers can make authorization code changes to their OPA policies required for regulatory compliance on certain applications and keep your environment secure.

3 . OPA saves time for developers. OPA acts as a building block that developers can plug in to any part of your cloud-native system to enforce authorization policies, making it easy to use. This ability to apply sweeping authorization policy changes across the tech stack ultimately frees up time for developers and as a result — lowers costs.

The current process for authorization will only create unnecessary work for developers to complete.

By setting the authorization standard with OPA, organizations can unify policy, better meet compliance requirements and give time back to developers. With these authorization advantages, developers can focus on what matters most — building innovative applications and driving growth in the cloud

Sign up for the Styra Academy, which has free OPA tutorials, today!

A version of this blog first appeared in Security Magazine on September 23, 2021