The Security Repo podcast: Why authorization matters more than you may think | Cerbos

Mai takeways of the episode

The ongoing challenge of authorizationEmre emphasized that authorization often takes a backseat during the initial phases of development. This oversight can lead to simplistic solutions that fail to address the nuanced security needs of growing businesses. He highlighted the importance of considering authorization as a fundamental component of the development process, rather than an afterthought.

The difference between authentication and authorization

For listeners new to the concepts, Emre clarified the distinction between authentication (proving who you are) and authorization (what you are allowed to do). He used the analogy of airport security for authentication and the permissions to perform specific actions within a system for authorization, stressing how these roles increase in complexity as they scale.

The benefits of using off-the-shelf solutions

Emre discussed how custom-built solutions often become unsustainable as businesses scale. He advocated for leveraging industry-standard, off-the-shelf solutions like Cerbos, which can drastically reduce development time and improve security by using proven, tested components.

Zero Standing Privileges (ZSP)

Emre introduced the concept of Zero Standing Privileges, explaining it as a dynamic access control that limits user permissions to only what is necessary at any given time, much like checking in and out of a hotel. This approach minimizes security risks and improves compliance.

The future of authorization

Looking forward, Emre shared his perspective on how regulatory environments are likely to evolve, emphasizing the increasing importance of sophisticated authorization mechanisms in meeting security standards and compliance requirements.

Conclusion

The discussion provides a treasure trove of insights into the often overlooked yet critical aspect of software security—authorization. We highly encourage everyone to listen to the full episode to gain a deeper understanding of the strategic importance of robust authorization practices and how Cerbos is paving the way for simpler, more secure implementations. For those who prefer reading, the complete transcript is available below.

To learn about how Cerbos empowers developers to implement, manage, and delegate fine-grained access control in software applications, in a fraction of the time spent building and maintaining it in-house, click here.

Transcript

Mackenzie: Hello everyone. Welcome to another episode of the Security Repo podcast. We have a pretty awesome episode lined up today, and we're gonna be diving into authorization. We've talked a lot about authentication on the podcast before. This is really the first time we are going in depth into authorization, and we'll explain exactly.

How that's different during the episode, but we have a great guest with us today. We have Emre Baran, who's the CEO and cofounder of Cerbos, which is an authorization management provider, which is helping software companies implement and scale fine grained access controls. He's an entrepreneur and a software expert with over 20 years of experience building and scaling B2B and B2C products.

This isn't Emre’s first rodeo, so to speak in the startup world. He was also the cofounder and CTO of Yonja.com, which was Turkey's largest social media until they exited from that company in the mid to late 2000s. He's also worked for a plethora of amazing companies, delivering amazing projects. So Emre, we're so thrilled to have you on the show and welcome to the Security Repo Podcast.

Emre: Thank you very much for having me. 

Dwayne: Yeah. So I wanted to bring on the show basically just to ask you, how is it 2024 and we're still struggling with authorization and authentication to some point, but really AuthZ is the. The big circle out there. Why is this still so hard? 

Emre: It's still hard because it's not the first thing developers think about when, when, when we're building a new product, when we have an idea, nobody thinks about authentication.

Nobody thinks about how am I going to log the user in? How am I going to store the data somewhere? How am I going to send emails? How am I going to check permissions? We're all very much so wired to. Build software to solve problems, solve big problems that businesses have, that people have all the friction.

So a lot of the software infrastructure is always secondary to what we're solving. And The second reason for that is a simplistic approach gets people a long way, right? They say, when you think about authentication, which is a username and password, look up, you know, there are still many websites out there that are, you know, in maybe design phase and they're all just.

It's hidden behind a very simple password that's been stored in an HD password file or somewhere else where the password is either one, three, three, one through eight or password or something very simplistic. And so number one, it's not the top of mind and the most important thing, but then. Once the software starts going and users start using it, authentication seems to be less of a problem nowadays because there are many, many more vendors out there that actually make authentication simpler for people to implement.

Many people, not many developers resort to doing their own username and password lookup. However, authorization is much more of a deeper challenge than authentication. It's much harder because it's often many people, including, you know, good developers or product managers, et cetera, struggle to define the fine line between where the business logic ends and authorization logic begins.

So It's so much easier to not think about it, just implement one role and, you know, kick the can down the road for when the business problem or a compliance problem or something else like that comes up and because it's not a such. such regularly, you know, practiced muscle authorization is still one of those challenges that everybody struggles with.

Dwayne: It seems like it's also just a holdover from a previous time that before it was like, everything's behind this firewall. Everything's in our data center. Everything's locked down. So if you can get in, if you can AuthN, we're just going to assume you got all the privileges and that's what I think you're, we're alluding to with let's just make a role for everyone here and like, you can get in, now you have your role and now we're back to the good old days where you just go hog wild, do whatever you need to do to get your job done.

Emre: That, that's, I would call that even a second phase of that. The first phase of it is like, I always say if you leave the world to software engineers, software developers, there would only be one role in every software product, and that'd be super user. And all of it would be super user and all those who can't even log in.

So and we, we, we, it's, it's a simplistic way of looking. Looking at any software challenge in any security, we are always in the software world. You know, there's a greatly known acronym YAGNI. You ain't gonna need it. And everybody starts thinking about stamping everything with a Yagni every time they hear something that's gonna, you know, take them more than a couple of minutes to implement or more than one sprint to implement.

They're like, do we really need it? And then they look around. Nope, there's no clear use case right now. There's no clear requirement. Yagni. Kick the can down the road. So it's a very common thing. And what you mentioned there is, you know, security perimeter security. And then once you actually log in, you have access to everything has been the norm as well with a lot of, you know, software architecture, which we can go much more deeper into that, into that topic.

It's. You know it's usually people look at security and they assume it's good enough right it's good enough to keep the bad actors away and that's where they stop 

I mean, what, what's, what's the real differences between those. 

Emre: Yeah, apart from a few letters in there. So authentication is the fact that proving you are who you say you are. Authentication is validating the user. Authentication is the act of logging in saying that I am this person and I'm therefore you know, I can prove it to you with my credentials.

If we think more of a real life scenario, Authentication. We always talk about, you know, airports is a good example or other things. Authentication is you saying, you know, my name is Mackenzie and you showing an I. D. To prove that authentication is that same thing thing that logging when you're logging into a system.

So I'm Mackenzie and you enter your email address McKinsey at and then you provide a password that only you probably support. You're supposed to know and the system says, okay, I trust you. You are who you say you are. Authorization is a step that comes right after that. Once you're actually logged into the system.

Now it becomes a question, what are you authorized to do? What are you allowed to do? What, you know, are you allowed to see everybody's records? Are you allowed to you know, edit certain records delete certain records? You know, maybe going to financial systems and issue a payment or issue a payment that's more than a million dollars, right?

These are all the different things you can do. Every action needs to be authorized and authorization is the, Is the act of authorizing every interaction with a system and not only saying is mckinsey is mckinsey as an admin allowed to do this and it's mckinsey as a user allowed to do this 

Authentication is kind of binary. It's are you allowed or not? Right. And then authorization is like, what can we do? And I feel like it's the logic flaws and authorization that an attacker could really, you know, exploit or bend the rules. And like using your analogy of the airport, you can really kind of see that.

Can someone sneak in, is there rules of, can I get into this door? Okay. And then what can I do beyon that? So I, I, I understand that a lot more and how much deeper. This challenge 

Emre: absolutely. As you've said, you know, the answer to the question is McKinsey. Is this McKinsey is a very binary question, right?

Yes, he is. No, he is not. However, when you think about an authorization, you can think of it as a house, right? Is McKinsey allowed to enter? The answer is no. But that's, you know, there's an assumed thing in there through the front door. Or maybe McKinsey is allowed to enter through the window or through the chimney and through the other places.

Right? So when you're actually thinking about authorization and when we think about software, there are a lot of APIs, there are a lot of actions, there are a lot of things that might be mutating the same object from different microservices, different entry points, and authorization needs to actually encompass different Every possible scenario and all the permissions that are around it.

Dwayne: Now we have a firm grasp on often versus AuthZ as they're often shortened there. Let's talk about Cerbos what, what you're doing over there around all this. 

Emre: Yeah, Cerbos makes fine grained access controls very easy to implement and manage. We service makes authorization more secure and more adaptable by change to changing requirements that while any piece of software might have and by doing so it saves months of developer time.

Often what we see in a lot of organizations is. It's built in house, you know, so everybody thinks about authorization security is important, but then the answer to it becomes, okay, we're going to write our own scalable and an extensible authorization layer. And often that act takes a good 4 or 5 months for a team of 3.

And that's basically an experienced set of developers. And all the servers makes that very easy to implement services off the shelf available. It's an open source, open core product that enables you to be able to configure it and implemented within minutes to days rather than spending months to build a whole piece of infrastructure.

I often very much so compare that to an analogy of databases, right? You can write when you're writing a piece of software. You can decide to write your own database and start from scratch to be able to store your documents. Or you can say, I'm not going to reinvent this wheel, I'm going to get something off the shelf.

It has a very clear API to how to store data and how to retrieve data. And I'm going to trust this technology to handle my document storage. With Cerbos, we're doing the same for authorization for permission checks. 

Dwayne: Yeah, it's not that different than Cerbos. Well, as far as reinventing the wheel, what we hear a lot on the market, it's like around secrets, like, well, talking secrets detection, yeah.

My developer can just write some grep, write some regular expression. And months later, they finally realized like, wow, we didn't account for all the overhead, all of the many. Exceptions, all of the edge cases. And then finally they're like, well, what's available off the shelf? Like, what, what can we go out there and, and, and get and I 

Emre:  If the very first use case is very simple to write for a developer, to write with three lines of code, you know, how hard is it, how hard is it to do? And, you know, logic check on a username and password. Does it match, right? How hard is similarly in authorization? How hard is it? To write a very simple if then else statement that says, if this user is a manager, allow them to see the screen and that's the fallacy that a lot of development teams fall into the very simple first use cases.

Very simple to do with a code. And I always talk about, you know, software developers, you know, given enough time and money, they can do anything. And just because they can, should they? That's the other question, right? So uh, Yeah. Yeah, I mean, it's, it's very simple cases are very simple, but then the moment you go into enterprises, the older requirements just go out of proportion and any sane developer who looks at it and says, this is not the core business problem we're trying to solve.

Why are we solving this? Why can't we actually just get something that's industry standards state of the art off the shelf and implement and move on and very much so focus on the core business problem we're solving. 

Mackenzie: Yeah, I think one of the core things, especially around security too, that as often an afterthought is, is this scalable, you know, when we're, when we were starting to implement something, you know, because it's, it's.

Security is kind of like you're there to protect your thing, right? But it's not the thing, whatever the, you know, the thing that you're trying to build is. So therefore you kind of implement some basic things and then you start scaling and insecurity really starts to drag you, drag you down, but implementing something from the beginning that perhaps may even seem overkill at the time, which I, I could spend hours talking about why it's not overkill insecurity, but anyway Like having that scalability there that will allow you to, and then security won't hold you back.

I feel like that's an element that a lot of, a lot of kind of startups kind of miss because it doesn't feel necessary at the time. But, oh man, can it make all the world of difference when you're trying to move quickly and add new features and new functionality, if you have something that's malleable with, with your tools.

Emre: And that, and that question is. Is this scalable? Comes in multiple flavors, right? Is this scalable? Number one, is this scalable to our new, new use cases, right? It's like new requirements come up all the time. New, new business cases, use cases security requirements, standards come all the time. Like is, are we going to be able to further develop and maintain this product and many software organizations.

Aren't equipped to have their own dedicated security team. Oftentimes these pieces of infrastructure in a lot of software companies is a team that's built cobbled together to build it, to architect it well, to think, Oh, like let's build this as scalable as possible. And then you know, hand it over, implement it and move on.

And then suddenly that team gets disbanded most of the time. That team now is back to their day job and new requirements come in. And since it's a very core piece of infrastructure that can halt everything or that can break everything, no single engineer wants to touch that alone, on their own. Suddenly, you start accruing tech debt just because of the fact that you can't actually pay for it.

Put together the same crack team who built it in the first place. And in the meantime, some of that team leaves the company. Suddenly the knowledge is gone. Nobody knows what this code is, what this code was doing and why. And so unless, you know, and then on the flip side of this, I want to also talk about, you know, when probably it's a good idea to go build it.

If you are Google, Facebook, Amazon, when you can actually dedicate a whole Team or 10 teams to your security and you're going to build your own the next standard for the world. Absolutely go build your own, but until then, you know, for everybody else in the long tail of software companies, it doesn't make sense to build.

Dwayne: But yeah, if you got, if you have the resources and like you say, if you're going to build a standard, like Google building Zanzibar, they built that for themselves. Clearly and openly, but now it's a standard we can all use. Thank thankful for them on that. Got a question for you though, on who owns this though, this is always a question, interesting question, security, because the developer, we keep talking about the developer, we keep shifting left and putting the developer, a security hat on the developer every day and asking them more and more to be security focused.

But ultimately who owns this? Is this the job of the developer? Is this the DevOps manager? Who's like. Did you think about Auth Z or is this the security team who needs to get involved earlier or does even making that distinction help anybody or are these just siloed teams that are going to pass the buck around?

Emre: So it depends. So if we, if we are talking about a large, Corporate company whose job, whose business is not building software, then we're talking clearly about the I. T. Teams to adopt something and implement and manage it. Right? So let's focus on developer team. So let's let's focus on software companies that are actually building software.

And when we look at Their life cycle, what we see is usually two co founders or one, one founder who starts it. What does that mean? That one founder is the HR manager, the CEO, CFO, CTO, CISO, DevOps manager, developer, architect. All of those roles are actually under one hat, right? One per under one in one head.

As the Organization starts growing suddenly these roles start separating into other human beings and within that when we look into that is like the very first one is the developer and the senior developer developer or the architect or developer and the tech leads. So who's ultimately making the architectural decisions about what the stack is going to be when you trace these kind of decisions that goes back to that very first split of who's deciding what the architecture is going to be, but once an organization that starts growing suddenly not only.

You know, new titles, et cetera, start coming in, but the roles, the split off the roles, like the cells dividing in half suddenly start becoming technical implementation and operational, right? So who's going to operate it? Who's going to, who's going to build it? And where in a standard normal software company, what we see a lot is there's an architect who decides it.

A developer. Or two that works with the work with the architect or the tech lead that implemented, but then a day to day operations of this suddenly is now more on the business user, whether it's a product manager, whether it's the customer success manager or see. So, and then as you get more and more customers, suddenly security becomes its own thing.

Suddenly you have an IT manager or a supervisor within customer success that actually starts allocating roles or managing who has. What kind of access to to which property. And then from then on, you know, when your customer success team becomes five, 10 people, and suddenly no one person can be actually trusted on their own, suddenly you start getting your it team to start managing these roles.

But. What's paramount in all of this is going back to what we were saying, if we leave the world to developer, there'd only be a super user and a read only user. 99 percent of the time, requirements start coming from the business side of it, either a customer is requiring more than one role, so because they have more than one people in their team to be able to do, you know, Complete their workflow, or as a company grows, the requirements start coming in from a chief information and security side, because now the company needs to be compliant with certain regulations to be able to separate roles and segregation.

Dwayne: You brought up regulation there. I wanted to ask you about. The future of regulations. Are we going to see more and more from outside the organization, like governance, literally saying, look, you have to account for authorization the same way that you did often at some point what do you think that looks like in the future?

Emre: Possibly. I mean, what we're seeing are. Two or three main things that are impacting the industry right now, right? So, number one, OWASP is doing a great job in highlighting the importance of authorization. The authorization or any vulnerability a company is exposed to due to lack of proper authorization is number one issue in OWASP 10.

Right. And up till two years ago, it was number three, and now it's number one. So what does that mean is people are actually paying more attention to this. It's, it's getting known people are realizing it's an issue. People are realizing some hacks actually happen, not just because somebody's Credentials late, but actually that person's access to a lot of things, right?

So it's actually a two fact, two gated issue. And the second one is, you know, there are more and more standards, global standards like SOC 2 or ISO 27, 001 and those. You know, in principle require you to have segregation of roles and permissions. The question is how well will they be in the future enforced and validated.

Honey tokens are fake credentials that you can put in your environment and also in your third party tools to know when there's been a breach. Compromised GitGuardian is free for all teams with less than 25 developers. You can sign up today at GitGuardian. com. All right, back to the episode. I want to kind of go a little bit deeper into, to some of these kinds of thoughts here.

There's a, There's a new term that's recently come out and security is always hard to kind of keep up with terms, but it's in line with the idea of of zero trust and that is ZSP or zero standing privileges. And basically, as I understand it, this is kind of when we don't leave. Access or authorization access to two things that are not used for a long time or on things that is kind of dynamically created.

I want to know, you know, is that is that correct? Maybe you could explain it better than me. And what's your thoughts on where we're going in that? 

Emre: Sure, so, I'll give you a good analogy for this one to begin with. Do you remember in old times when you used to actually check into a hotel, the receptionist gave you the key, you went to your room, but you were actually expected to leave the key at the reception when you were actually leaving the hotel?

Usually these keys had like very chunky key chains that were attached to it. 

Emre: So that, that is, you know, a type of zero standing privilege. As long as you're in the hotel, you have access to your room, but when you're leaving the hotel, you're going to leave your key.

And the beauty of that is. You are, there's one less attack vector where you are less prone to lose your key while you're. Not at the hotel, you know, you're outside, like, it's one less chance of somebody nicking your key outside of the hotel and coming in, going into your room. So, zero standing privilege is a similar thing in terms of on a day to day basis, when you're actually there to do your job.

You're allowed to, you know, perform your actions, but then it's, you know, after after hours, your privileges are revoked. There are a lot of authorization systems that actually handle this very simple policies that go with these are, you know, some people who are all they're only allowed to access a customer record between nine and five.

Which is assumed to be their work hours, which by the way, with the whole remote working and everybody being in different time zones becomes harder, but we can go into that separately and similarly things around, you know, it's like we've seen, we used to see this a lot again with post COVID it's less so, but there were a lot of systems where there were policies being done.

And it was like, you're only allowed to access certain things, whether, while you're actually in the office. And if you're outside of office, there were certain actions you couldn't do. Even, you know, during COVID, a lot of trading banks and trading platforms, you had to be in the office to be able to do those, to do those trades.

And and, and if you were home, you know, people actually had to go to banks to work out during COVID times. So zero standing privilege is very similar to this, right? Zero standing privilege is you only have the privileges in certain conditions. Otherwise you don't have them. And so nowadays it's becoming easier to manage as well, because as authorization is being decoupled from core code, authorization is actually managed on its own.

Implementation of such rules are trivial to your authorization layer, and in the old times, it might have required you to rebuild your entire application code or had to require To redeploy your entire application because somebody had to actually make changes to who has access to what or not. 

Dwayne: Is that making it easier on the developer side to, I guess, push that concern later?

Is that, that's my biggest concern right here is zero standing privilege. Like, well, isn't that just a giant blocker for the dev team early on? Like you, you care about functionality. You care, does this thing work? Can we get an MVP out the door security? Like that's, I think that's why security comes in later in a lot of cases.

Emre: That's exactly what we said in the beginning, right? So security is actually is not the front and center of mind. Everybody's trying to make their product work. So I'm going to answer your question a little bit opportunistically here and commercially. That is exactly one of the use cases for service, right?

When a developer Implements an authorization product. The developer does not care about the number of checks are being done. The developer is implementing a very simple API that they can actually query from anywhere on their stuff in their stack. They can always ask the question. Can this user do this action on the street source?

And the API says allow or deny. So as a developer, You implement that and luckily you offload all of this logic change and cumbersome logic building to security teams to product management teams. So now, because it's a policy, it's much easier to evolve and change of change those at any given point. And the impact to developer is 0.

Developer has implemented that API. The decision that comes back is a fact is a result of what's implemented in the policy, all the rules that are in the policy. 

That you've heard and what's the worst that you've that you've heard or received or even perhaps given but Let's, let's start with the best. If you could give our audience one piece of advice to help them in security, what would that be? 

Emre: It would be assume nothing, right? So this is almost a little bit of an extension of a zero trust security, right?

Assume nothing has seen just because some, a user is. You know, has been through secure certain gates, uh, it means they're saying that they are who they say they are, or they're proven their privilege to do that. This is something that's becoming more and more important in a microservices environment, right?

So the fact that a request is coming into a system. What does it mean? Let's assume nothing and, you know, computation times are only getting faster. There is not much of a cost of checking credentials or checking you know, authentication tokens, etc. So, assume nothing is a great when it comes to security, you know, to to validate your assumptions about, you know, always validate your assumptions, always check privileges.

Emre: Over the years, I mean, I can.

Worst one. One off, one off. I'm, I'm going to cheat a little bit, but I'm, I'm going to actually talk about one of my pet peeves that I see there are systems out there that actually force you to change your password every month or every three months or so, but while doing that, you can just re enter the exact same password.

So those are, those are my pet peeves. It's, you know, some of them now says, oh, it can't be your last password. Some of them say your last three, but there are many systems out there that you can, including some banks, I've tested this. You just re enter the same password, hit enter, and then it basically, that alarm is snoozed for the next three months.

Weird. You have to think of so many scenarios when you implement the stuff yourself. Yeah, exactly. When you're using the correct tools and systems, things like this, hopefully are already built. 

Emre: So then if it can, I guess the relevant one, worse security advice is, Oh, build your own. So this is that much exact.

It goes in the same way. Oh, it'll be, it'll be so much easier, cheaper, faster. You'll know everything about it. Absolutely. For one use case for 10 lines of code that any number of lines of code that's not going to go beyond your comprehension or beyond your capability. It works the moment you have more than one person or one use case.

It's an absolute disaster.

For service down in the show notes. You don't have to Google that Dwayne, any final words before we click the big red button? 

Dwayne: Just want to say, thanks for being here. I met you as you were literally being the face of the company, not just leading the company, but literally the person at the booth by yourself promoting the.

Your product while you're giving talks at events. So if you're in, you said Iden Con, you're going to that this year. 

Emre: Identity verse. Identity verse open Source Summit and Q Con Europe are the next three events. 

Dwayne: Alright, we'll be on the lookout for you out there. And, 

Emre: Absolutely. My Twitter X handle is Emre, my first name, E M R E. Pretty active on LinkedIn as well, Emre Baran. And then for Cerbos, just Google Cerbos, C E R B O S. And we have a bunch of Twitter and LinkedIn and YouTube social media for Cerbos going on. You can find them all at the bottom of the page. 

Thanks again. 

Emre: Thank you for having me.