Emre Baran, Cerbos | OSS North America 2023

This is techstrong tv. Welcome back to the Open Source Summit in Vancouver. I'm here with Emory Barran from Serbo, and we're talking about authorization.

Welcome to eo. Thank you for having me. Sort out a very simple thing for me, if you don't mind.

We talk about authorization, we have access management, we've got identity conversations going on all over the place these days. What is the difference between all these different things and when do I use what for what? Yep, Absolutely.

So, uh, very basic security is compromise. Uh, four different things. Authentication, directory, authorization and accounting.

Sometimes also known as audit. Authentication is about your identity. Are you who you say you are?

It's logging in into a system. Do you have the right credentials or are you, you know, are you not trying to be somebody else? Then comes directory, which is about, uh, who are you in the organization, which groups do you belong to?

Are you a manager? Are you like a regular employee? What departments do you belong in?

What geography you belong in? That's all the, all the directory information. Then comes authorization.

Once you know who you are and where you belong, are you actually allowed to perform an action or not? Are you allowed to edit this record? Are you allowed to view somebody's social security number?

Are you allowed to list all the possible options for a given thing? And then comes audit, which is actually a record of everything you have done is, uh, this is classic audit trail that people actually keep track who did what when, and whether they were allowed or not. So that makes the authorization, the security layer in every software application.

Are we maybe not paying enough attention to certain elements of that? Because seems like every time I hear about a security breach, I see the phrase privilege escalation. And that sounds to me like somebody's authorization was higher or granted to them than they should have had, or somebody managed to hack into somebody's system and make it look like they were somebody and then they escalated from there.

Absolutely. And what we see in the industry, the very common reason for this is actually, uh, developers having building their own auto or their own security layer, whether, you know, the joke we have within the company is how hard is it to look up a username password table, but then billions of dollars later, you actually have proper, credible companies like Okta actually providing those services. Very much so like cryptography where you shouldn't be actually writing your own crypto and using actually industry standards, but it's very similar in authorization.

You shouldn't be actually building your own authorization layer and using industry standard, very hardened systems. And often all of these breaches are a result of, you know, some, somebody making a system very easy to try million username and passwords out combinations for somebody just giving, uh, a user of a system too many access privileges and when their account gets compromised, some bad actor can actually do many, many other things. So why aren't people rolling their own?

Because what you're describing to me is not the business logic of the application where they're adding value. It's a, it's an important function, but it's a function nonetheless that, you know, is fairly common, right? Absolutely.

And it's, it's standardized, right? Every, um, every software has this layer. The reason, uh, very simple reason is, you know, engineers are very capable of launch.

They can say, oh, I can build that, I can build that. And the very basic requirements of authentication or authorization are very simple to write in computer language, but a very simple if then else statement. However, a lot of these things aren't enough as the use cases get more complex as the requirements or regulations get more complex.

And when an engineer looks at the problems like, oh, I have to do just this one use case and solve it, it's a very simple thing to solve with their code. However, there's so many other requirements, so many other corner cases that they need to actually look into. When a software developer is building a business application, they don't have enough time to focus on this indated part of the stack.

They actually want to all build business value and they just, you know, gloss over this with a very simple thing and saying like, maybe I'll come back to it later. And guess what? Business requirements and revenue and everything else usually trumps a lot of these requirements.

And security is not one of those things where everybody thinks day in, day out because it doesn't, you know, it's one of those table stakes features that you need to have. However, it doesn't add an additional value to your business unless you get a breach and it actually you have, you know, and some negative consequences of it. So what is the alternative?

What are you guys doing to eliminate the need for me as a developer to go do all those things manually myself? Uh, we ultimately at sebos make that authorization layer. We very much so focus on authorization and not every other part of it.

So there we will integrate with all the authentication providers, we integrate with all the directory providers and log processing companies. And at Servos what we do is we standardize this authorization layer and make it very scalable and extensible without you having to spend 3, 4, 5 months trying to build this infrastructure layer and maintain it. In many, you know, startups and many early stage or even late stage software companies, there isn't a dedicated security engineering team who just focuses on the software security infrastructure.

Oftentimes they, you know, they use in, uh, industry standard libraries for crypto. Uh, they use a system like of zero fusion of and various other, um, authentication providers. And within that realm, services provides the authorization, which we make it very easy for developers to implement it in about five minutes.

They define the roles and they get an API that they can work with while having an industry standard extensible and scalable system that's gonna paraform really well, Are the bad guys kind of counting on us messing this up? And so they're kind of look sniffing around and going, Hey, this is, uh, just perfect. Once they get past the identity layer, they steal somebody's credentials, they're probably looking for a poorly implemented authorization environment going, and that's when the party begins.

From their perspective, I, I'm not sure if they're specifically hunting for this, but a very classic first step, a bad guy once they go get into our system is knock on all the doors trying to figure out what they can do and what they can't. And a very common use case is, uh, regular users having too many privileges in a given system. And with systems like Serbo in a regular, uh, developer built environment, if they haven't paid attention, a manager is capable of doing everything right.

So you actually say an admin can do everything however, uh, and in order to compartmentalize those, uh, those security privileges, usually developers now have to do more work to be able to restrict it. And admin can only edit, for example, the users point a given period during the day, during the weekday from an office, uh, location, et cetera. So bad guys, of course try and knock on every single door and see what they can get away with what they can do.

And if you haven't built the infrastructure to be able to restrict all for all these different requirements, you are exposed to all these possibilities. We're seeing a lot more conversations about regulations around the world. Do you think developers are gonna be held more liable for this kind of thing?

And, and cuz it seems like they're all saying, well, if you took reasonable precautions, we won't, you know, throw you in the clink. But what is the definition of reasonable precautions? Um, so one, one of the reasons why we see the authorization getting so much attention right now is absolutely that there are require, uh, regulations like ccpa, GDPR in Europe, making sure that a, you know, when you've been hacked, when you know, uh, you have to report when some, you know, bad actors has gotten into your system, has done things that they weren't supposed to do.

So at this stage, co developers themselves are not held responsible individually, but when you look at gdpr, eh, companies are held responsible and chief data officers are actually personally liable if they don't report any of these breach breaches and they can actually go into jail for. So we're getting, we're seeing more requirements come into play, and that in turn creates requirements to, uh, develops your software more, um, reliably more safe, safe and secure. So I'm not sure in any day soon a developer will be put in jail, but, you know, companies start feeling the pressure and of course that will trickle down To that end.

How much of this is essentially an invitation to a failed audit if I do it myself? Because there's auditors out there that are gonna be looking for this stuff and Absolutely. And you know, if I'm know I'm gonna fail an audit, why do, why do it wrong in the first place?

So, uh, audits like SOC and ISO 27,001 have this requirement in there knowing that who did what when being able to produce a full action log of who tried to do something. So, um, the issue is not having the requirement in there. The issue is when a company is be actually being audited by the comp, uh, by a, a security company to pass their audit, um, how de how, how are they really looking into it?

How much are they really looking into it? In many organizations, when they go through those ISO requirements or software requirements, they just generate a very simple log of everything and say, look, we have it in there, but, uh, the requirements are getting year after year more strict about that. A very good example of this is, um, you know, historically it's been a, a log requirement of logging of actions who to who did what, however, now what's becoming more important?

Who tried to do what? And they were, they actually failed being able to record the failures and not only recording the successes of who did what. So all of these are things that we build into our products so that we can actually expose these data points.

And as we expose these data points, organizations become more aware of all these requirements. Who's making this decision? Is it the development team or the security people who are showing up driving this conversation these days?

So the decision is made by two different groups at two different times in a given organization in very, in a very early stages. It's usually the decision is made by a technical architect or whoever is, uh, assuming that role. Um, in some, you know, very small startups is a co-founder cto in a larger company, it's a VP of engineering and even enterprise level companies is a technical, excuse me, technical architect.

And that is very much so the technical requirement of, you know, what product should we use to satisfy the requirements we have. Uh, in here the business requirements usually come from the product management or chief information and security officer side. And then as an organization gets more, uh, you know, robust and you actually start adding dedicated people for the CIO and cso, uh, cso, um, roles, the, those requirements actually now generated and they start taking a number in the backlog of all the development features that needs to be done, get, needs to get prioritized and everything else.

And again, this is one of the biggest problems we see with organizations because most of the time those requirements don't rank high enough when compared to all the revenue generating, uh, possibilities that a developer can spend their time on. At the end of the day, a product man product and develop engineering teams have limited resources and they need to prioritize everything that's sitting in their backlog. Everywhere we go these days, somebody's talking about policy is code, can I get authorization policies as code?

Absolutely. That's one of the things that we actually enable. Making sure that all of your policy, all of the requirements, all of your, uh, security policies as immutable policies, sitting and making it human readable as simple as pulse, as simple as, uh, English.

We have, um, there are many products out there where you can write si, uh, policy as code, but it's actually written in a programming language. You still need some translation by an engineer to explain what it is. But one of the key things that we have actually very early on focused on SBOs, making that immutable and making it as simple as pos as as plain language as possible.

So anybody when they look at it, they can figure out what's going on in here. Mm-hmm. Do you think therefore we'll see more DevOps teams getting involved in this conversation?

Because ultimately they want things that are repeatable, testable, explainable, observability, this is where they all live. So is this gonna be part of my pipeline at some point? Uh, we already make it part of your pipeline.

So, and what we see is, you know, the shift left movement rather than DevOps, this is actually now becoming more of a job of a developer because ultimately what, uh, authorization products, what they're really doing is they're productizing all these requirements as early as possible and making it, you know, uh, adjacent to your business requirements, adjacent to your business and needs. Uh, we are seeing, you know, DevSecOps, uh, as the new term that we there that exists, but a lot of the, whether it's DevOps or DevSecOps, many of the, the genesis of the requirements, genesis of the, um, what's the right word? Um, Request Of the request are actually now being addressed by developers themselves because they can, uh, new authorization tools that are available make it a very simple for them.

So they don't need to be actually specialized in that. You cannot walk down the street without somebody talking about AI these days. So will AI get applied to authorization management?

Absolutely. Uh, the, as I mentioned very early on, one of the key, uh, key parts of the security layers actually audit and knowing who did what when. And that's a great data set to be able to train your AI models, figuring out what was a legitimate, uh, request, legitimate action, what wasn't.

So when we look at an authorization layer, what authorization layer does is in real time makes decisions about whether you're allowed to do that or not. Uh, today many of the policies, many of the application of policies are done based on rules and these, you know, policy as code, but soon, uh, we can see a future where those decisions are actually dynamically made by ai. You know, as humans, we are not in, we're, we're fallible, right?

There might be a policy that actually leaves a corner of, um, you know, a corner open for a, you know, bad actor to come in and take it exploited. But if you have, let's say, a user who's never done a certain action and suddenly taking that action in your system at 3:00 AM around the world, in other part of the world, the chances are potentially that's a, you know, bad actor and AI should be and will be able to catch that and block it on its tracks. So what is that one thing you see organizations doing over and over again that just makes you shake your head and go, I think we're better than this.

Um, the key thing that we see in many organizations are going back is like building their own security line. Um, and it's, it's the not, I mean, in the past they weren't great tools that scaled, well fine do it, but the attitude that we see is like, oh, we can do that. And then they don't actually open their eyes and looking at the possibilities of, you know, specialized companies building these great tools and making them available, especially in our case, making it available for free for two developers.

All right, folks, you heard it here. Just cuz you can build it yourself doesn't mean you should. I'm ready.

Thanks. Thank you Very much. All right.

And we'll be back in a minute.