I’m going to argue that access management is one of the most pressing issues facing developers today, and that the hodge podge of UIs and JIRA tickets that we’re using for it opens us up to serious vulnerabilities. At the risk of some major hubris, I will pattern my argument after The Imitation Game. This is the game from the seminal “Turing Test” paper where Alan Turing proposes a way to test for artificial intelligence.
Alan Turing, father of DevSecOps
I propose to answer the question, “Can I get access to this thing?” This should begin with definitions of “I” and “this thing”. “I” am a human or machine that is trying to get work done at a cloud-friendly organization. A cloud-friendly organization is most likely where you, reader, are working today. Your business mostly runs on AWS, GCP, or Azure, and you depend on tons of SaaS services and internal tools to make things happen. “This thing” that you want to access is one of the resources in this web of cloud, SaaS, and internal endpoints.
Let’s replace the question “Can I get access to this thing?” with another. The new form of the problem can be described in terms of a game. It is played by three entities, a requester (A), a resource (B), and an owner (C). In the simplest form of the game, A and C are humans sitting in the same room together, and B is some digital resource that C has both domain expertise about AND has admin privileges to.
In order for C to “win”, they need to decide whether A should get access to B. In the simple form of the game, C can simply ask A why they need B. Since C has all the domain knowledge required, they can decide if A’s reason is sufficient. Since C also has admin privileges to B, they can grant A access. Since A told C why they need access, C knows when they can remove A’s access as well.
We now ask the question, “What will happen when a machine takes the part of C in this game?” Will this machine still be able to make the right decision about whether to give A access to B? Will this machine know how to actually grant A the access that is required? These questions replace our original, “Can I get access to this thing?”
Why not just hire a captive workforce and allow no new access grants at all?
Is “Can I have access to this thing?” really that important a question? When Turing asked “Can machines think?,” that was and remains obviously worth thinking about. OK, granted. Access management friction is perhaps not an existential problem… but it is a fundamental issue for teams that are trying to get work done within the constraints of modern business.
We’re losing the authorization game, and it is putting our businesses at risk from both a security and efficiency perspective. People who have overprovisioned access are breaking things. A script at Atlassian accidentally cascade-deleted tons of customer data. A compromised engineering account at Uber breached tons of sensitive access. If we try to manage these risks, we typically end up grinding work to a halt. Teams are stuck waiting for access, or are forced to create workarounds that in turn lead to new security and efficiency issues.
We cannot play the simple version of the authorization game and also scale our businesses. We need a machine to replace an omnipotent and omniscient resource owner (C). A properly designed machine can account for all the inputs and context we’ll need to actually make authorization decisions at scale. Our new question improves on “Can I have access to this thing” because we’re not all in the same room, basically ever. We don’t have all the context and all the access.
This is less complicated than what you're doing for access management today
The surface area of AWS alone in your organization easily consists of hundreds of combinations of discrete services and accounts. Layer in GitHub or GitLab, Okta or OneLogin, CloudFlare, DataDog or SumoLogic, StatusPage, Sentry, Segment, Airtable, JIRA, Slack, CircleCI, Notion, Ngrok, PagerDuty, Terraform Cloud or Spaceship, Honeycomb…. You get the idea. There are a lot of services to consider here.
The complexity of authorizing access is both technical and organizational. From a technical perspective, there is no standard way to implement authorization controls across all the services that modern teams need to manage. Some services have complex RBAC systems, some have a few roles, some have easy to use APIs, some use SAML or OIDC, some require creative workarounds to achieve your desired authorization outcomes.
Finding all your domain experts and getting a slice of their time ain’t easy. In a single “service” like AWS, the expertise to decide how to set up access to DynamoDB vs S3 vs SageMaker vs EKS might be wildly different. AWS is just one of many services you’re likely depending on, each with their own quirks and internal usage patterns that needs to be considered when making an access management decision. There’s no central oracle with the knowledge of how authorization should be set up in each service.
The kicker is that even if you are lucky enough to identify all the domain experts you need to make good access management decisions, you’re still kind of out of luck. When you ask one of your domain experts “Can I get access to this thing?” they’re not going to say “Sure!”. What they’ll say is: “Well… it depends”.
That’s because access management decisions in a modern business are dynamic, context-dependent things. Your access rights depend not just upon who you are, but on the full complement of what, when, where, why, and how you’re doing something. If you’re investigating a customer issue, then maybe elevated data access makes sense… for a time. If you’re standing up a new application with new AWS service dependencies, maybe you need more sensitive AWS permissions… until the application stabilizes.
The question which we put in 1 will not be quite definite until we have specified what we mean by the word “machine”. In short, it’s a system that (for now) combines human and machine inputs to automate access management decisions. You ask the machine for access, and it decides if, when, and how you get it.
In order for Access Management Systems to win the game, they’ll need to address all the problems we highlighted in section 2. They will need to:
And if that’s not enough, we need all of the above to be at least partially (ideally completely) automated. We won’t be able to build either a secure or efficient access management system if a human has to do each of these steps every time. We’ll overload people with requests and context switching, resulting in slower work and poor decisions.
Cool hackers are available to help you remove access management friction
The best way for an access management system to win the authorization game is if teams can manage the system in code. When you use code to define your access workflows, you represent not only the happy path for access, but also the edge cases and nuances that are specific to your organization. Using code to wire in our integrations means we can meet target systems where they are. You define infrastructure in code because it is cheaper to build, easier to maintain, and more resilient to change. If the tools are there to provision your access management system in code, shouldn’t you do that, too?
Provision in Terraform, route in Python, approve with context in Slack
Sym is an access management system that can help you win the authorization game. Sym gives teams a platform that is opinionated enough for fast development, while also extensible enough to integrate into the specific needs of your environment. The key building blocks you get with Sym are:
Sym’s platform starts with human-in-the-loop workflows because we want you to have an access management system that doesn’t need workarounds. By starting at the human review layer, we ensure domain experts make access decisions when necessary, and give them the right context to do so.
Customers integrate with PagerDuty to adapt their workflows to on-call status
As your usage of Sym grows, we help you codify and automate more and more of your access decisions. We know that it is not practical for humans to review every access request, and that is why we’ve built adaptivity into our flows. Our PagerDuty integration, for example, lets you adapt access requirements to the requester’s on-call status. You can use our SDK hooks to wire in more adaptive controls, and we’ll be building more in this area over the year. (Talk to Max).
Benedict Cumberbatch plays Dr Strange as well as Alan Turing, and he looks kind of contrary here
Turing’s paper lays out many objections to the question of artificial intelligence, including arguments from theology, math, and extrasensory perception. I haven’t encountered theological objections to our efforts to improve access management systems. I do think it is worth calling out, however, how Sym’s take on the authorization game fits into the wider landscape.
Sym helps you win the authorization game because we help you integrate context and actions from across your tech stack. Identity management systems like Okta or AzureAD do a great job of asserting who you are, but get stuck when trying to define what you can do. Rego and Cedar let you express authorization logic in elegant languages, but don’t help you collect all the inputs and outputs you need to make your access management system function. No-Code tools help you get started quickly, but fall flat when it comes to change management and covering edge cases.
While Sym still has plenty of room to grow, we’re making it generally available because of what we’ve seen our customers already achieve with it. Orum uses Sym to manage temporary access to Databricks and AWS, as well as for conditional deployments to CircleCI. Courier and many other customers use Sym to manage access to internal admin tools and to AWS. Other customers use Sym to safeguard access to sensitive HIPAA-compliant environments in Aptible.
Try Sym and get started building your own access management machine! Teams are struggling to work safely and efficiently because they need access management systems that are dynamic and adaptive. We need tooling that identifies domain experts, gives them the right context to make access decisions, and codifies the process so your businesses can scale.
Sym gives you the building blocks to win the authorization game, and we're excited to see how you use them. As Turing concluded, “we can only see a short distance ahead, but we can see plenty there that needs to be done”.
It turns out that the framing of Turing’s paper, along with the section headings (and even some of the topic sentences) worked well for the Sym case. At least it was fun for me to write it this way, and if it makes you go back and read his paper, even better. Thanks to Myles Steinhauser for having breakfast with me last week and inspiring this ridiculous idea.