On Friday morning, April 7, 2017, Okta's co-Founders, Todd McKinnon and Frederic Kerrest, rang the opening bell at the Nasdaq stock exchange. Okta's IPO signaled a growing trend in corporate IT: identity in cloud security. From their S1:
Our mission is to enable any organization to use any technology, and we believe identity is the key to making that happen.
By 2021 Okta took the top spot in the Forrester Wave for Identity as a Serviceand today Okta is a leader in the growing identity and access management market which is projected to be worth $34.52 billion by 2028.
The concept of identity was first implemented in 1960 to prevent users from going through other people's files on MIT's Compatible Time-Sharing System (CTSS). CTSS users had to prove they were who they said they were - a process called authentication - by entering a password. Neither Okta - nor its competitors - invented identity. But they did help pluck it out of a stream of access management primitives to promote it to a first class concept. Identity is the nexus where various authentication methods meet a sprawling landscape of SaaS applications, cloud providers and internal systems.
An identity provider (IdP) simplifies life for employees by making portable identities available through a single sign on (SSO) portal. They don't need to remember a password for each of the many apps (over 80 on average) their company uses. But the real benefits accrue to IT security professionals who are in charge of managing corporate access. Identity provides them an abstraction behind which the complexity of authentication and its many integrations can be contained. Most security breaches can be attributed to human error and it’s the complexity of corporate IT systems that is the root cause. Identity helps reduce complexity by centralizing authentication policy management through hundreds of integrations with SaaS providers, authentication mechanisms, and directory services.
The problem is, it’s not working fast enough. The Identity and Access Management (IAM) market reached $15.9B in 2022, growing 3.6x over the past ten years - an eerily similar rate to the increase in cyberattacks over the same period. The impact of security breaches costs corporations trillions a year, and much of the compromised data is owned by hundreds of millions of real victims: the end users. The situation is grave enough that in 2021, President Biden signed an executive order to galvanize efforts across the industry to stem the rise of cybersecurity attacks.
If identity is one of the most important movements in IT security, why is it not having a bigger impact stopping security breaches? The sheer scale of breaches can make anyone feel like cloud security, with identity at the center, is somehow deeply broken.
The question we explore in this article is: what comes after identity? Do we need something more or something else altogether? Let's see if we can figure that out by starting with software fundamentals.
The eternal enemy of well-functioning software teams is complexity and the software engineer's weapon of choice is the software abstraction. The startup Modular are on a mission to reduce complexity for machine learning engineers. Modular's CEO, Chris Lattner recently railed against complexity in an interview:
The bitter enemy in the industry is complexity … by simplifying this complexity, organizations can save time and money, and researchers can focus on what they do best - developing and improving machine learning models.
Security breaches are often blamed on employees but the real culprit are the systems that failed to adequately curb complexity. Security can get the most benefit from the same tool developers use to wrangle complexity in software systems: abstractions.
Consider the code required for creating a new user in a typical SaaS application. The following is taken from the FastAPI tutorial.
Real world implementations may require more logic than this starter example but this "simple" chunk of code already encapsulates a massive amount of hidden logic, supported by tens of millions of lines of code, written over person-centuries of effort. The software engineer only needs to concern themselves with the essence of their app's business logic. Virtually all other details, stacked in layers and layers of abstractions below this code, are dealt with.
From Lattner:
By raising the level of abstraction. Now, you can fit more things in your head by being able to just directly leverage someone's library.
It's not the infinite lines of open source code available that gives developers this power. It's the availability of libraries with well-designed abstractions. These are the libraries that won adoption against competing alternatives because they had the superior approach. Good library authors find the right cut lines to create building blocks capable of stacking. Poorly written code resembles spaghetti and is impossible to use to create an enduring structure.
One concern FastAPI users can safely ignore are the networking details powering the communication between the browser and the server. The data contained in the user object passed to the create_user function above arrived over an extremely complex exchange of packets between the server and the browser and had the help of many intermediaries facilitating transfer, routing, encrypting, and decrypting. The networking stack itself represents a set of well-designed software abstractions that enabled the rise of the internet. Jim Keller provides a superb description:
When things are beautifully done, usually there are well-thought-out abstraction layers. The whole thing works in unison nicely … they work together but they work independently. They don't have to know what the other one is doing. So the famous one is the network stack. There's a seven layer network data transport protocol … they really got that right … the layers could innovate independently and occasionally the layer boundary with the interface would be upgraded. And that let you know the design space … you could do something new in layer seven without having to worry about how the others worked. And so good design does that … humans are only so smart and we're not getting any smarter, but the complexity of things is going up. So, a beautiful design can't be bigger than the person doing it.
Software companies that commercialize software abstractions won't get adoption purely on the merit of their abstractions. Not all software buyers seek out and appreciate the beauty in software design the way Jim Keller does. Even if you've invented the most precious abstraction since the networking stack, it doesn't mean anyone will care. A previously unknown abstraction needs to be packaged and promoted in a way that enables the idea to spread through an industry organically.
It takes a massive amount of marketing for a startup to become a big company. Marketers often position their brand by associating it with well-known concepts to leverage previously established popularity and trust. Examples in cybersecurity include Shift Left and Zero Trust. These are essentially memes (in the Dawkins sense) that have spread with the help of thought leaders and marketing budgets. To become meme-worthy in the first place, an idea must resonate enough with buyers and end users such that it becomes assimilated, retained, and transmitted to peers.
Every once in a while a startup will take a software abstraction and successfully commercialize it to become a big company. It's often because they identify a meme at the beginning of its ascendance and align their marketing to leverage and amplify it. An example from the developer tools space is LaunchDarkly who helped pioneer "feature flag". Because of their efforts, "feature flag", now represents a software abstraction as well as a set of best practices; its a now a full category with its own competitors, created using an effective meme. Feature flags are a system that allows functionality to be turned on and off by changing configuration instead of changing code. They enable a whole slew of benefits including: non-technical people can make product updates, each update carries much less risk, and it becomes easier to test product variations.
When the company was founded in 2014, the "feature flag" was better known as the "feature toggle" and had been promoted as a best practice by Jez Humble and Martin Fowler. Today, the more popular term, feature flag is alliterate and depictive of a more robust control than a simple, binary "feature toggle". After LaunchDarkly’s efforts, the industry, (including Fowler) began using feature flag more. A lot more.
As the term became more familiar to developers, LaunchDarkly started promoting best practices enabled by feature flags, like continuous testing and testing in production. Soon, the concept was known to engineering leadership, product managers, and marketers which expanded the GTM vectors and made it easier for buyers to get budget.
But why are we talking about memes? Our goal is to bend the curve of rising security breaches and we’ve established that we can do that by reducing complexity with new, powerful abstractions beyond identity. But if no one hears about our abstraction, no one will use it. The most impact is made by the ideas that achieve the farthest reach. To maximize our impact, we can learn from other companies. Okta provides an ideal example of how a software abstraction was successfully brought to market.
Okta's primary abstraction is identity. They've contributed to, and benefited from, its meme-ification. The importance of identity in cybersecurity has grown significantly over Okta's 14 years. Today, the concept transcends industries and departments. It's considered of such strategic importance that companies like, Bank of America, JP Morgan, and Walmart have discussed identity-related internal initiatives in recent earnings calls.
Okta's founders started with a different product idea: SaaSure, a monitoring tool for SaaS apps.But after collecting feedback and hearing recurring pain points around supporting employee logins, they decided to build their company around identity.
we talked to about probably 50 people about SaaSure and that product mockup. Right in the beginning we pivoted to identity because they kept telling us that: "this monitoring is kinda interesting, but the problem I have now is people login into their windows PCs on my network and everything works great until they have to go to Box or until they have to go to Salesforce. So just solve that problem. Make the login to these apps work like they’re on my network."
Todd is Okta's CEO and in this conversation he goes on to explain that this problem of multiple logins, was one he was familiar with.
I knew enough from my time at Salesforce … and my experience at PeopleSoft that, just to build simple cloud single sign on, you had to build a lot in the backend, you had to build a directory service and integrations…
Labeling Okta as "the cloud SSO company" might have made it a bit easier to position the product as the most direct solution to their customer needs, but they chose instead to market Okta as "the cloud identity company". Identity could also be associated with their early customer pain-points and it allowed Todd to paint a picture of a future large company to investors and employees. From an interview with Mike Maples:
We knew that we wanted to build a very big impactful tech company, and then we knew that if you started from this pain of just logging into cloud apps and you built the infrastructure right, you could build a substantial product suite around that that did everything from synchronizing user directories to doing multifactor authentication, and we knew that you could build a big company off that, because I think sometimes companies … find a pain but it's just kind of nichey, right? It's never going to be really big …. there was pain for cloud single sign on.
Embracing identity was a smart move, but Todd may not have realized exactly how far identity-as-a-meme would have to run over the next 14 years. The year after Okta's faithful pivot to identity, John Kindervag introduced zero trust which is today's ultimate cybersecurity meme. It builds on the idea de-perimeterization introduced in 2004 which promotes strengthening internal defenses using identity and placing less emphasis on the external boundary. Zero trust currently dominates mindshare of the cybersecurity industry and is only growing in importance. In May 2021, the Biden administration issued an executive order mandating U.S. Federal Agencies adhere to NIST 800-207 as a required step for Zero Trust implementation.
Todd quickly identified urgent customer pain points, and with his engineering background (formerly leading engineering at Salesforce), built a platform and team that could pump out integrations at a quick pace. It was smart positioning and excellent execution that allowed them to get early traction quickly. In recent years, much of Okta's success can be attributed to how they've been positioned as the cloud identity company and then how the rise of zero trust helped put identity at the front of the cybersecurity buyer's mind.
Zero trust is an evolving standard in its early phases of development. It will be a useful guide to help us determine what comes after identity. Before we dig further into zero trust, let's look at identity's primary flaw.
In 2002 Joel Spolsky created the Law of Leaky Abstractions:
Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions.
He uses the same network stack praised by Keller to help illustrate the concept:
TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from.
Identity leaks because authentication leaks. In the most extreme case an attacker will obtain a developer's credentials to access sensitive data. Authorization decisions are made on the assumption that the identity is valid. In the case of compromised credentials, identity fails, a lot.
There are other examples where identity fails a little. Authentication is meant to prove that you are who you say you are and many factors can be taken into consideration including device identity, location and previous activity. But zero trust implementations use many of those same factors during the authorization decision which is downstream of authentication. In fact, the 800-207 ZTA reference says that the authorization decision should consider: "is access to the resource allowable given the level of confidence in the subject’s identity" which suggests that an authenticated identity is not an unassailable contract. "Confidence", as used in this description, could be taken to be a measurement to which the identity leaks.
But as Spolsky points out, "all non-trivial abstractions, to some degree, are leaky." Identity is certainly a non-trivial abstraction. It never had a chance of not leaking. Though its flaws are targets of increasingly creative cyberattacks, the industry has come together to figure out how to plug the holes. Passwordless technologies like FIDO2 along with biometric devices and improvements to MFA are helping to make identity less leaky. Okta is one of the vendors leading the charge.
"After identity" doesn't mean identity is going away. It’s still the right abstraction to build upon in workplace access management. Like in any good software project, we need to continue to harden existing abstractions while always searching for the next one that can tame the next chunk of complexity. After identity means we need to build on identity’s success by discovering more complexity-crushing abstractions.
Published in 2020, NIST’s Special Publication 800-207 is the current working version and canonical reference to a zero trust architecture (ZTA). To find new, useful abstractions we’ll start by looking for ways the ZTA standard could be improved.
The ultimate decision whether or not to "grant access to a resource for a given subject" is made at the Policy Decision Point (PDP). It works with the Policy Enforcement Point (PEP) to make and enforce access decisions. Everything else is data, context and analysis provided to the PDP to make the decision. The reference doc zooms in on the trust algorithm used to make the decision.
The Subject Database includes information like what roles (RBAC) and attributes (ABAC) the user has. These are combined with Resource Policy Requirements to determine what permissions the user has.
According to the principle of least privilege, the permissions available to a user should be only those that the subject needs to perform the immediate task. The document states the importance of least privilege but falls short in providing guidance on how to achieve it. It states that "Access rules are made as granular as possible to enforce least privileges needed to perform the action in the request." But the there are no tactics or mechanisms specified to keep the scope limited despite that fact that this is a real problem on the ground. For example, nearly 99% of cloud IAM policies are overly permissive.
The NIST document also states that rolling out zero trust updates to your network requires a “tuning phase." I’d argue that, with the push to more granular permissions, tuning becomes less of a discrete phase and more of an ongoing process. The more granular your permissions, the more updates they will require. Employee's access needs change as their projects change and what passes for least privilege one week might be overly permissive the next. The easier it is to update permissions, the better administrators can adapt to day-to-day changes and minimize the risk of a breach.
Here is an opportunity to build on the zero trust architecture and specify systems where updates to permissions safe and easy, so adherence to least privilege is a reasonable task for administrators.
Here I propose an automated workflow to make permissions updates safe and straightforward. The workflow should generally follow four steps.
This is a common process that seems simple but is often the source of toil and errors. By automating it, we can streamline the process and remove much of the pain. A workflow engine to support automated permissions updates would ideally have the following characteristics:
With these attributes, it becomes very easy to request, approve and grant and revoke permissions. We now have the tools to support temporary or just-in-time access. We can then seek out and remove permanent, risky permissions in our IAM systems and make them available for a specific duration, behind an approval. Temporary access allows organizations to scale back default standing access, significantly improving their security posture. It's no wonder that temporary elevated permissions is a cloud security trend that is gaining momentum.
We've elevated the “permissions update” to a first class abstraction which requires many supporting integrations and a sophisticated workflow engine. By doing this, we make updates as safe as possible by providing context to the right stakeholder at the right time. We also make it easier, increasing the chances of making more permissions temporary access workflows, thereby moving closer to least privilege.
Assuming we've created a useful abstraction, we need to package it in a concept that will both capture the value prop but also resonate with security professionals. Our abstraction makes it easy to adapt our permissions allowing the ZTA trust algorithm to make the best authorization decision possible. In this way we've provided security professionals with a new super power:
Adaptive Authorization
The ZTA reference emphasizes the importance of least privilege but falls short of providing guidance on how to pursue it. Adaptive authorization provides a way for everyone in the organization to participate in an ongoing process of keeping permissions as tightly scoped as reasonable, including adding a time dimension to access. It allows approvers to modify auto-approve rules iteratively, at the point when the context is most fresh reducing the reliance on quarterly access reviews. It helps improve and streamline permissions updates to help organizations better tune their access toward least privilege.
It may seem silly to spend so much time on memes in an article about security breaches, but I wanted to draw a complete strategy and that includes successful distribution. Even the best products don’t win if they don’t achieve distribution. As Justin Kan said: "First time founders are obsessed with product. Second time founders are obsessed with distribution." If this abstraction has a chance of creating a category, it will need to get picked up and spread organically as a meme.
Access management is not the only attack vector for cyber criminals but its a common one and represents a significant chunk of toil and complexity in cloud security. Adaptive authorization is one of many new abstractions that will be needed to make a dent in security breaches by making access management stronger.
While Okta chases the customer identity market, companies like k9 Security and Sym are focussed on new ways to help administrators wrangle the complexities of access management in the workplace. Along with many other security startups, we are earnestly chasing the next abstraction that could make a real difference in reducing security breaches. The company that makes the biggest impact will be the one who capitalizes on the next meme. Where that meme comes from … who knows. It could be found in the next version of the ZTA reference. It could even start with an idea introduced in a blog post.
