Hudson Thrift, Head of Internal Security at Uber, outlined the benefits of attribute-based authorization policies.
Thrift began his keynote presentation at the 2019 CISO Leadership Forum: Security 3.0—Shifting to Automation, held in San Francisco on April 9, by defining certain concepts he’d be using in his talk. “An ‘attribute’ is metadata that describes a person, object, or action that’s grounded in an inherent aspect of that object, an ‘authorization policy’ is a rule that defines whether an actor has permission to perform an action on a resource, and a ‘role’ is a job function or title that inherently defines an authority level. To make this talk simpler, we’re only going to be talking about actor attributes,” he explained.
“What are the different kinds of authorization-policy strategies that exist, and why would we prefer one over the other? The first and most straightforward is what I call a direct grant, which is made to a certain person. The next level of granularity makes a policy grant to a group of people. There are good reasons to use each of these in different environments and for different purposes. Direct grants are very exacting—they indicate exactly who should have access, and we can look at our policies and understand who has access. The downside is these are difficult to onboard, and there’s a highly centralized operational overhead. Groups are still fairly exacting, and they spread the ops cost to the group owners. The downside is it’s often unclear why people are in those groups, and it can be difficult to recertify without a lot of overhead,” he stated.
“With attributes, access is understandable and auditable. For example, there’s a sentence that says if you’re an engineer in INSEC who’s passed training, you should be allowed to write code. Exactness is correlated to the number of policies we have. Every time we want to be more exact, we add another attribute-based policy that allows us to be precise about what happens, Thrift said.
“The cons include requiring a lot of infrastructure to handle attributes and exceptions, and generating these policies is super hard. To address these, you first need a central identity repository that’s the sole source of truth for identity in your systems. The second piece—which is the meatier problem of the two—is how to generate the policies if you have all this infrastructure. First, you need to generate all policies centrally. I don’t think application owners can reasonably be asked to make policies with attributes. We need to score every policy so we can explain why a policy is good or better than another policy.”
Thrift then explained the math used to calculate the overall health of a system and of certain policies. “Overrepresentation is the main function of what we’re doing—basically, we’re looking at the population of people today who are currently restricted and looking at the group we’re trying to target. We want to find the most representative attribute within that target group versus the population—which attribute is overrepresented in the target group versus the population. This gives us a ranking of our attributes in terms of what’s most differentiating. The overrepresentation analysis is then done again with the top attribute removed from the stack. We re-rank the attributes, pop the next one, and go through. That will get you to whatever the local maxima of score is for that set of decisions. Out of this, we get a candidate policy for which we now have a score that tells us how well it’s working,” he explained.
An audience member commented, “It sounds like you’re trying to get to a single sign-on concept—signing on with one user ID and password and porting the other authentication architectures back to that model. Is that a fair statement?”
“We have single sign-on today. You only log in once.”
“You log in once, it’s set up so you can create those authentications in your model, and those will propagate down into the vendor solutions you’ve adopted. That’s nontrivial,” noted the questioner.
“Yes, that was a tricky one.”