The Yin and Yang of Zero Trust Policy-Based Automation

Hello everybody. I'm Patrick Parker. I'm the CEO and co-founder of Empower id. I worked on the product team and the product research team. So we're here to talk about the yin yang of zero trust policy-based administration, and I'll explain what that word salad means in a moment. So the spark for this talk, the inspiration came from an interesting source. This time I saw interest, I think Ian and some of the, some of the, the participants are in the audience here.

I saw Ian post an article that he pulled something from his way back machine, I think it was from back in 2010, where he'd written something where he was promoting for, to satisfy the auditors that using negative authorization or denying access in your, in your access policies to make the auditors happy, to eliminate some of the risks. And then that immediately, Andre, who's in the audience here, somewhere from there he is, there he is, right there. He jumped on it almost immediately. And he said, I, he wished he'd never seen this posting at that at completely against negative authorizations.

That you really only do negative authorizations if you don't fully understand how authorizations and identity governance works. Pretty strong. But it was, is it good? It got the, it got the argument started, and then some other people weighed in.

Kevin, I dunno if Kevin's here. Kevin was originally a Burton later at Gartner. He got in the, in in the mix. So it was a lively discussion, very interest. So there was definitely an interest. And for someone who loves authorization, it was nice to see because for a long time at the conferences, almost all the discussion was on authentication. You go to everything about authentication, multifactor, authentication, authentication. And it feels like now looking at the, where the funding's going in companies, where the discussions are online, some of the innovation.

I see Jerry, I saw Jerry out here somewhere. Hey, Jerry, back there.

Hey Jerry, some of the innovation that's happening that now there's an emphasis on, okay, maybe we have the authentication silos not solved, but at least you know where we can workable then and, and multifactor authentication. We have some, some good standards and building blocks there. Let's move on to the uncharted next frontier, which are how do we deal with authorization? All these different silos that have completely distinct authorization models. There's no compatibility to translation layered, no centralized reporting that makes sense of it all across systems.

So you can have nice policy based aro that are applied across systems and an understanding of access risks and, and the meaning of the access across systems. So the, the, the discussion's definitely going now seems to be getting some funding. Seems to be getting some interest. So that's very heartening to see.

We, and we have a lot of new tools since authorization is now becoming a hot topic. We have new tools or new frameworks like Zero Trust, which has a very large emphasis on least privilege lease privilege. Granting only the required access for an authorized purpose for the least amount of time is, is, you know, a key component of zero trust. We have that in the mix Now is something that's been broadly accepted. Zero trust is a good model for securing organization.

And as we mentioned in the beginning, policy-based access, Andre went very deep in his discussion of policy-based access and why well-crafted policy-based access if it was an implicit denial. And unless a policy is created and a least privileged zero trust model has no need for negative authorizations, that they only add complexity. And what are negative authorizations?

Well, negative authorizations are, you know, blanket rules. Like if you're not above this height, you're not allowed to ride the ride or you will never have that access under any circumstances. So that's negative authorization. They're very, and and they have a lot of downsides. They have a lot of downsides.

They, they're a reactive approach. They're very, they're a big hammer. They're not very, you know, they're always gonna deny no matter what they, they can make a mess of trying to figure out the resultant access that people have, which are some of the, some of the arguments that were made. And they can lead to a lot of complexity, which equals cost and complexity in security can lead to risk and vulnerability.

Which, but because they're just very simplistic and really easy to understand, they're, they're not going anywhere. Google, I think this was 2022 intro introduced denial policies because the allure of a denial policy is that I say, you will never be able to do that.

I, I can go to bed, bed at night and not have to worry that you're gonna be doing that. Cuz it's a denial. I it's very simplistic. It's even understand, seems like something that, you know, is enticing even given the downsides.

Now, risk management, on the other hand, kind of the sister of denial, a little more sophisticated, maybeI negative authorizations is the country cousin of the sophisticated city cousin from, which is risk management. Risk management is based on a concept of what can you do with this access? How risky is it? If you would be able to create a purchase order, how risky is it if you're able to, and then which data you can access, access accessing this customer data versus this, you know, just documentation. It also focuses on threats and their impact. So there's a measure of how bad is this risk?

And, and, and you're thinking through if it happened, how bad would it be? What would be the impact of that risk? They're completely independent of access policies, access grants, and your risk policies typically aren't intermingled in your access policy. So it keeps it simple and they, they can prevent risky access, so prevent it from being granted. And they can, they can ta they can deny it, they can detect it as well. And one thing about risk policies, which we'll talk about is that you can choose with a negative authorization. There's no wiggle room.

You can choose with a risk policy to allow it, even though you know it's a risk, you can just accept and mitigate the risk. So I used, you know, chat G P T and I I fed in as context the dis all the discussion comments plus Ian's article. And I had it generate a, a, a debate. So have we have robots debating each other? Taking your position, taking his position and arguing it. So on the pro side, so I'll be the pro robot, basically negative authorizations give you an extra layer of protection that no matter what you have in an access policy, you know that certain things aren't gonna happen.

And I'll be the negative debater, I'll be the other robot that they can lead the complexity, they're unmanageable, they create chaos. It makes it hard to tell what's going on. And if you have a well crafted policy, p a policy with zero trust or negative by denied by default, then you don't even need it. I do what? But then you don't have a fail safe. You still need a fail safe and you ha and you need multiple layer layers of protection.

If you just have your access policies and you're, you're betting the farm on everything being handled by these access policies, well you can, and automation's not gonna eliminate that. So completely, you can't eliminate this complexity by automation. I don't even want to hear that. So positive authorization, strict adherence to zero trust or denied by default will give you a high level security without resorting the negative authorization. So we'll leave it that they didn't really come to an agreement.

But, and, and I'm not here to settle this debate at all more maybe to more inflam it, keep it going. But really in my opinion, you know, that the, the access, the po, the positive, the yang, the light, the is the yang granting the access that really it is interdependent and requires the, the yin that you need. The negative, the either negative authorizations or risk management has an even better alternative, which you did not argue against that you need them to balance each other to create harmony. You need both. They both need each other.

You really can't just have one without the other and have harmonious balance. And, and the reason for that is that you have to think about, in my opinion, the practicalities of crafting these p back authorization policies where it's denied by default.

Unless I, I grant the access in a policy, I don't have to worry about somebody having it. But then you think about payback, everybody wants to think, well, we're pushing it down to the business. Business users know this information business users, that's the mantra everybody says in marketing, which never happens, that business users are gonna craft these policies. Well then if you start distributing it out, then you have everybody who has a different level of skillset and different level of knowledge of the other policies.

So unless you know, you can see all the possibilities in your head of all the feedback policies and all the things that aren't supposed to happen and all the things that have been authorized, then you really can't be feel safe that you're, you are preventing the risky things from happening without any type of protection. You're basically jumping out of airplane, in my opinion, without a parachute. And with policies add on that nice extra layer that, you know, some risks are maybe acceptable for your company.

In a big company you'd never let this person perform this action like creating a purchase order and approving a purchase order. But maybe in a small company that you have to, you have to wear multiple hats. Practicality, you want to know it's a risk. You want to mitigate it and accept it. Say we're gonna watch what that person does, but you have to allow it. You can't just have a blanket denial that just, so risk policies give you a maybe.

So now maybe we can use, maybe we can have these p back policies with a risk policy and then we'll achieve this harmonious world where all of our applications, you know, application authorization, nirvana, and everything's working out great. Sounds great, right?

Well, I hate to be the party pooper, I'm gonna bust your bubble. But unfortunately reality is too messy. We're all dealing with lots of applications.

Legacy, you know, we don't, we don't have every application, oh, you have a P back. So oh, you have, you have a PB pdp, you have a policy decision point where I can plug in and get realtime authorization decisions.

Great, that's great. It's out there, it's ready. They're waiting that we got it up.

We're, we're gonna launch it. Every application owner point your application at it, right?

Oh, wait a minute. Oh wait, wait, what?

You can't, you can't call it, you're, you can't call it, you're not who nobody's gonna call it unless it's a custom app. Nobody supports external authorization decisions at runtime.

Well, we built this beautiful thing, we have this yin yang harmony here. What, what, what, what's going on?

Just, it's gonna sit here. So that, that's reality is that unless you're building an app or you have an app that's already plugged into where it's gonna cost some extra authorizations for us, it's your PDP is gonna be sitting there waiting by the phone, hoping somebody's gonna call it and it's not gonna get cold. So what do we do?

We, we know we need policies. We know we have a terrible problem on our hand that, you know, Gartner keeps blaming us that we are the problem and maybe the right, you know, preventable misconfigurations 99%.

That's, that's, that's pretty harsh. We know we need to do something. So thankfully, you know, Martin's shining the light.

Well, policies and automation, that's the, that's the key, right? Well, okay, well policy and automation, how are we gonna do it? Well we can pull out, you know, grandpa's tools. If you mention the word GRC risk, people think, you know, e r P systems, sap, they think something like this's not really cool at all's a grandpa's technology. You're not gonna get any young people on board recruiting them to work on grc. It sounds old, it sounds terrible, sounds clunky, but there's an answer. People invented it.

You know, it is a little bit more marketing than you think. So wait, what, what could we call it that would make it cool for the kitties and their Kubernetes and their, their cloud worlds and APIs? Oh wait a minute, let's call it guardrails. Guardrails. Everybody loves to say guardrails. Guardrails. Feel like I'm in tron, got the guardrails keeping me in here and everybody, the guardrails are everywhere. Guardrails, guardrails. Everybody.

If you haven't written the paper on guardrails, you better pop a paper out soon And it's says the way to get your name out there is right, something about guardrails, everything's a guardrail. Putting guardrails on our cloud configurations, we're putting guardrails on everything. Well if you look at it, risk management grc, hmm, those are guardrails. So why don't call it grandpa's two anymore. Say we're gonna do risk guardrails, fine grain authorization, guardrails. So now it's cool, everybody wants to get involved in, in guardrails. Sounds sexy, right?

Yeah, love it. What other cool term can we put in there? And this one's for a very practical purpose, but if we, if we plug our P back in, we have our guardrails now we still have the problem that we author our policies here in time, this time and then the user is performing the action here and we don't have a real time call out for authorization. So you're authoring a policy here and then typically right then a provisioning engine is granting that access course grain, not fine grain, no context cuz how could it have context? It's like six months before you're gonna try to do the thing.

There's no context about your IP sub that. So what if we pull out something else that might change it? And we said okay, if we have, if we author the policies here but we don't provision the access until as close as possible to when you need to use the access and maybe not all access, just risky access. So you author the policy, you and then only just in time maybe upon request roll activation elevation as they call it in pam, you elevate. And if you elevate you could close that time window to where maybe it's even elevating for a day or maybe even for the length of a session.

Then you have context then you know, where are you? What's your IP subnet, did you do mfa?

You know, all kinds of cool stuff. So now you can plug in your cool P back policy where you don't grant the access or provision it unless you have meet all the criteria of this very fancy pvac policy, which also has guardrails. So there you go. So now plugging that all in, and I think I was one slide ahead cuz of this. This is my guard, my my my shift. You shift just in time.

So author the policies here, you don't provision risky access, you provision it just in time and now you've given the opportunity that you're more closer to having context and having somewhat might, might approximate real-time, extra authorization. Even though it isn't because, and you can check mfa, you can do all kinds of cool stuff as long because you're closer to the point in time where they're gonna use the access and you can have more contextual information, you can do some other things with it. And that's it. Thank you.

So I heard you talk about PDP policy decision points then there are policy administration points and a lot more. Yep. But I think if I hijack these, I think that could be a very nice attack factor. If I hijack your policies and I'm able to change them, gone with your security. If you get my policy, I think you need some governance on that also. Who policy you'd have To hack the enforcement point. Pardon? Because if the enforcement point is just, if you get my policies, then you just basically know my rule book.

But that doesn't get you, you'd have to insert yourself somehow into the enforcement of those policies early. Yeah, Yeah, that's exactly the attack factor. I was meaning, but yeah. Yeah. Okay. Well thank you. It's very interesting. I'm really curious to see how this all develops. Well thank you. Thank you. Thank You Patrick. Thanks.