Hello, Richard Hill Lead Analyst at Cooper Cole. And today we're having a webinar about advanced authorization in a web 3.0 world. This webinar is supported by Indite and joining me today is Lase Andreessen, founder and CEO of indite. But before we start, here's some information and some housekeeping notes and then we'll jump into the topic of today's webinar. Now for some housekeeping, everyone is automatically muted so there's no need or worry to mute yourself. We'll be running some polls during the webinar, which we'll be sharing the results shortly afterwards. And we'll also be recording the webinar in both the recording and slides will be available on the website. In addition, we'll have some time at the end for question and answers. The go-to meeting control panel has an area to type in your questions at any time, which we'll answer during the question and answer session at the end.
So let's take a minute and we'll start looking at the agenda for today. I'll start out by talking about authorization access, controlled decision making, how it continues to evolve through innovation and why complex access control use cases require more advanced forms of authorization. And then I'll turn over the webinar to lase who will talk about authorization challenges, some opportunities and benefits of knowledge based access control solutions. And finally, as I mentioned, we'll save some time at the end for question and answer session. So let's take a minute to take our first poll. The poll question is on the screen which you can answer and enter your selection in the webinar paint. This question really is to get a sense what's driving you to watch this webinar? What's peak in your interest? Are you just curious about authorization solutions? You wanna understand more about the trend direction or key security authorization options? Maybe you have an RFI or r p going or maybe just heard about Incas approach to authorization. You want know more. So go ahead and enter your selection and we'll show that poll results a little bit later.
So moving on, let's start off by understanding, you know, what drives organizations to evolve its method of authorization in the first place. And what I've seen in experience working with organizations, whether you're a new company or maybe you're just starting a new IT initiative of some kind, at some point you start off with a tool that makes authorization decisions of some sort and then you have some kind of process or mechanism that allows you to onboard a digital identity bound to a person or thing, authenticate that identity and then you're ready to just check to see if that person or device can have access to a resource of some kind in the beginning, you know, use cases for this kind of authorization. Checks are typically well defined, mapped out to resources to be accessed. So really you're on that happy path. Then maybe the organization grows or new initiatives and more complex use cases. So you try to fit your authorization tool to cover those use cases and you may need to push the limits of that tool in order to get it to do what you need it to do to fit those more complex use cases. But over time you may realize that it's getting harder and harder to maintain that tool and so you're no longer on that happy path.
So your solution architect or equivalent your company starts investigating a new technology and product solution that could handle the more complex type of use cases and trying to make that tool more easier to maintain, at least for that five year technology plan. Starting with initial set of requirements, you may send out a request for information or an RFI to vendors and based on that information you get back, you may refine the requirements and move on to a request for proposal, create a short list of products or solutions, perform your demos and test it out, and then purchase the best tool that fits the use cases. And then finally you integrate the new tool into your system of systems and now you're back on that happy path able to more easily adapt to the complexity of those use cases and maintainability of that tool. Of course, until more complex use cases drives you. Back to step two. And really this is the reality of IT security field that we're in. And we typically tend to struggle until we can adapt.
For example, there was a time when access control is were sufficient for most cases and like trying to get into an event of some kind. And a guard at a door may ask you for your name or identity and then it checks to see if you're on the list and either you're on the list or you're not in access control list include rules to assign different levels of permissions to access files or other resources, but it's considered a very course grain access control. But you know, don't get me wrong, there are cases in which ACLS can be still effective, for instance, to like to enhance network traffic performance by limiting network traffic acting as a gateway of some sort. As an example,
At some point ACLS became insufficient to address the new complexities and use cases. Larger organizations needed a way to control access to resources based on their employees roles and responsibilities. And this brought about that role-based access control or our back to popularity. And sure, you know, there were basic forms of our back as far back in the seventies, but it wasn't until it was formally model being presented, which was proposed back in the nineties before it became very popular. Compliance, excuse me, driven use cases was one driver for this change. But it's also the ability to become more granular in rules and have less administrative overhead, at least at the time. Our back allows a user to have multiple roles where each role could have a specific permission assigned to them allowing access to certain resources. It did help with a level of flexibility by adjusting roles and permissions periodically. But you know, it also definitely helped when that SOC separation of duty compliances were asserted back in the early two thousands. But of course as the pattern with IT security more complex use cases came into scope and a new way of addressing these use cases were needed.
So those use cases included protecting access to data networks, devices and other IT resources from unauthorized users and actions. Also, the users needed access to an organization's resources where no longer just human users but also nonhuman things, machines and IOT devices and bots organizations also became less centralized, more distributed in nature. So other concerns required context to consider such as, you know, when and where are resources accessed And this drove that evolution of authorization in the attribute based access control direction or aac. Of course, you know again there were early experimentations of AAC in the beginning, but it really wasn't until Oasis that organization for advancement of structured information standards began standardizing it back in the early two thousands and then it started gaming popularity and that extensible access control market language that they standardized on ORAC mold was introduced to provide that standard way of implementing a back. And it provided, you know, things like a policy language model and requests and response protocol as well as a reference architecture and AAC allowed for that incorporation of ACL's roles and other attributes sources.
So it's reference architecture also includes a policy decision engine or a point to evaluate the attributes in a policy to render decision, which is typically a permitter deny in the exact world. And this gave the ability to abstract that authorization decision from applications and allow applications to delegate that access decision rather than reinvent the wheel within an application. And since other forms of aback have been used but is it's typically custom implementation by vendors within their products, policy based access controls or PBA is also typically in the background has attribute base but focused is primarily on the policies which advises that policy engine rather than focusing on the attributes himself. And that provides the policy decision point with information. There's also open policy agents or opa, which allows you to have policy as a, and this also works with nested JSON data and it is become very popular with microservice based applications and services.
But in general when defining a dynamic access policy, there are some basic components to consider. The subject is that user entity attempting access to a protected resource. The access defines the type of operation that the subject would like to perform on the resource like a read, write or function in an application resource is the data or service or system that the subject wishes to access. And then here at the context attribute of the access control policy really aids in that dynamics. It's that dynamic authorization term, making it context to where and potentially more risk intelligent in the sense. So for example, attributes about an environment or time of day geolocation current threat level helps to make more actionable decisions about access to resources. And with all these policy aspects really data quality is key when information from different data sources are tied to these attributes, it's meaning or value should be the same across different data sources. So this is really where organizations struggle or challenged by. So looking at the cola identity and access management reference architecture, it consists of a variety of different areas or building blocks, which can be considered core parts or categories of identity and access management such as administration, authentication, authorization and auditing any as you can see in the top right of the diagram, dynamic authorization management is firmly in the authorization category, which could also be used to control the other verticals to the left of it. This is where Cooper, Nicole sees the dynamic authorization fitting into that Im stack.
So dynamic authorization provides authorization to resources such as applications and data and other sensitive asset dynamically in a real time commonly using attribute based rules and policies. And some of the dynamic runtime authorization patterns could include API access patterns that provide a front end authorization mechanism for managing and enforcing authorization policies for services exposed via APIs. So the, you know, the policy enforcement points can typically authenticate API calls via API keys or tokens and then there's API gateways that provide inbound and outbound request authorization or authorization. And then there's auth also things like externalized authorization managers or eam which externalizes all or parts of the access decision from applications as an example. I mean typically EAM would query a policy information point such as a directory or virtual directory and to map groups or roles or attributes to entitlements. There's also cloud patterns like federated runtime access or OAuth access patterns that extend basic web access or API access authorization to clouds by passing security tokens about users or devices to PDBs to its author to make authorization decisions.
So this graph is from our dynamic authorization management research document from Cooper Nicole. And what this graph shows is that dynamic authorization is a mature established technology and the drivers for future use of this technology is its ability to handle complex access control use cases that include finance and privacy for example. But really the story doesn't end there, the IT security use cases are continuing to become more complex. And you know the question based on what I've seen is you know what comes next. So we are beginning to see the emergence of relationship based access controls, which describes authorization log logic by describing the relationships between objects and organizing access or permissions based on relationship between those resources. And this is often implemented by a graph model of some sort and it's also known as a knowledge graph which at its most basic represents real world entities as nodes and edges represent the relationships or the connections between these nodes. And knowledge based access control could be another name for this as well. And I won't get too deep into this since we have an expert with us today. So, but relationship based access controls offer to help with some of the more complex use cases that come up in areas such as data governance or fraud detections and other areas as well.
And then this graph here shows is based off of the Cooper Nicole has seen in the last access management leadership compass regarding the types of authorization mechanisms or techniques being used in the market today. And this is based on my evaluation of 28 vendors in the access management market and it shows that nearly a hundred percent of those vendors support some form of our back, slightly less for AAC and p a, which I interpret is being well established in the market. So those are things that you could expect and solutions today, but we're also starting to see signs of relationship based access controls as well with close to 40% of the vendors supporting it in some form. So we'll pause now to conduct our second poll and the question is on the screen you can feel free to enter it into the poll right there in. And so the question is around authorization access controls, you know, what do you see, what does your organization use? ACLS is kind of antiquated but there's still some use our back feedback, relationship access controls that are all above. So go ahead and enter your answer and I think I will stop there and turn over the next part of the webinar to lase from indite.
Thank you very much Richard and good afternoon to to you. How are
Excellent. Really good introduction to kind of like the past and look at where we are today. I, my folks today is gonna be more on on the future and what I see and where we are going. I had the privilege to work in a fantastic company before I started kind of like indicate one and a half year ago and starting from scratch it has some kind of like unfair advantages because you can pick the latest and the greatest post from knowledge but also from technology and only move and look forward based of course on everything we kind of like learned in the past and at indicate and also from in the identity world it, it couldn't be more exciting. It is so much happening, there's so much opportunities and coming from the identity space and very focused only on the top corner of of the space, I of course a lot of stopping is happening in in the web web three world.
And so wow, how are we gonna support that? How are we going to go go forward? Also at the same time knowing there's a lot of web two world that's going to stick around for a very long time and you can't come from a A to B kind of like without building bridges. So that's something that you need to keep in mind. And then also looking all that information, all that identity data you have and looking on this as connected data, making an actionable said Wow, this is a gold mine. It it's of course it's runs security and all your access control on that stuff, but the same information is really, really valuable for, for doing other things. And the way we were thinking about it in IndyCar when we started in in February, 2021 was what do we try to achieve instead of kind of like selecting technology A and B and C and how is the world looking today?
And of course we were really, really focusing on the design principles first and then of course either picking technology that already existed that could actually fit that, those principles or the good news. We also kind of like are doing a lot of innovation and creating the missing bits and pieces and of course privacy. Everybody wants to return control back to the users. We want to be data driven, decentralized, we don't want to have conflict a couple of governments or big companies controlling everything we're doing and, but a lot of that information is information out there is already these already centralized now decentralized. So if you have information databases out there, it doesn't make sense to kind of like put everything into a data lake before you can start because you can actually access a lot of information where it sits. And for me, not everything kind of like belongs to on a, on a ledger.
So we're pretty pragmatic and looking for what are we trying to achieve and then kind of like selecting the tools that we think support this in in the best way. The, again, it shouldn't be for more fun. The number of growing identities is just kind of like skyrocketing. And of course there's more bots, things APIs out there than human humans on, on, on the planet and all these have identities. Everybody should be treated as a first class citizen out there. And of course the complexity with this both from a scale perspective, we have several cloud environment, how do you do this in a HigherEd world? So there's a lot of things that we kind of like need, need to figure out and we need to come to to the next level and get away from kind of like these static on-prem systems and and look on the new challenges and also get away from kind of like identity is only about humans.
No, there's more other stuff connected that actually also need to be taking into considerations. So that's why we talk about identity of everything. And I just said kind of like we need to treat everything as first class citizens and in this beautiful picture here kind of like, yes there's persons, there's cars, there are buildings, and guess what? There's relationships between them. I actually own a car, I actually have a family, I have three fantastic kids which I'm father of. And if you look on these kind of things, all the different type of identities you have out there, they're all first class citizens and starting to kind of like adding information but what is the relationships, what is the metadata around it? So I own a car or I'm a father of and if you start to kind of like draw these lines, you get, I at least I got a kind of like a picture in my head, doesn't this actually look like a grass?
And I think you're right and seeing kind of the kind of like growing of this technology out there is just amazing. And you see kind of like, I think so much stuff of any type of application in one form of stuff can actually leverage or have take advantage of, of graph. So at IndyCar we're sitting there and say, Hmm, this is kind of interesting, couldn't this actually also do something for the more complex use cases where you have everything connected to our relationships, you have more metadata around it. So said, if we actually kind of like take that technology and add knowledge on top of it because it's not kind of like enough to only have have a graph, you need to kind of like understand the relationships you need to earn to add a lot of metadata to actually get more and more value.
And on a security perspective, this gives you a lot of flexibility. You can do kind of like really really fine reigned authorization decisions in real time and not kind of like change everything just because there was a new kind of like parameter coming in or there was a different context. You can do this high scaled in real time and get a more and more fine way authorization out of it, which we call K back, which kind of like I I would say is kind of like re back on steroids, but at the same time you have all that information, you can do really, really good fine wind authorization decisions and why don't you also use that same data and the same information for do other types of stuff because it's only comes about kind of like what are you asking the knowledge graph for? Are you asking for an authorization, which is actually is a decision, it are kind of like this device or this person or whatever allowed to do whatever in, in specific context.
But you can ask other type of questions to the same backend infrastructure and it suddenly actually can use it for for, for insights. It could be a recommendation that we, we all know from kind of like Netflix and, and Amazon or you can start using it for discovery for figure out kind of like how many devices are connected to a specific city or household or whatever. And of course the more you know about have this data available, you can also do very, very nice personalizations. Again, the sign principle number one, the end user actually owns the data. So you need to have consent that's, that's a table stake, that's a given, but you can use the same same software for so much more than than only K back. And I think the where we're we're coming from is is kind of like see this of course with one of the services that we have built out, if this is kind of like what you need and, and we also see that with the knowledge with the graph technology and also using machine learning from from day one, it's a game changer.
The, because one of the, the biggest problem kind of like in the identity world when things grows, it's actually how do you handle policies because this gets kind of really, really hard to manage and there's no kind of like magic happen with machine learning that kind of like suddenly everything is automated. But I would say kind of like trying to automate, taking outcome administration kind of like task by looking on patterns and say, you know what, this policy have kind of like never been used or this policy actually is really, really the same as the other policy. You can start fine tuning and automate a lot of the decisions as things actually grows. And the way we look at machine learning is I don't think you can do software development without having machine learning in in your toolbox. It's not an afterthought. It's not kind of like something you stick outside your house and use from time to time. Modern soft development actually use machine learning as one of the techniques they embed in in the service.
So again, what are we delivering and how do we do it? We're born in the cloud and we are only in the cloud. Our platform indicate ID runs out there. We don't do any on-prem thing at all. And I think the the key thing we're trying to to do with our platform is actually to making it easier for developers to get new fantastic applications, services, apps out there really, really quickly in the identity role. I think we have been really, really good of externalizing authentication. Many companies have done that in, in a really nice way. The next thing we should actually do is when we develop new applications, it's also externalizing authorization and making sure that kind of like you don't stick that into your business logic, but just call and externalize service like Indi kit for for making those those those things happen. The way we are trying to, to help developers of course is to giving access to our cloud indicate ID platform through either you use one of our SDKs depending on kind of like if you're on iOS or whatever kind of like client system you're on, we can also give you straight access to to all our APIs if you want to have even more fine grain control on what you're doing.
And what you're seeing here is is kind of like our backend console where if you are more a system admin type and you want is set up for instance different application spaces, so test, development, test and production, you have full control of all the environments. You can move between them securely, you can set up your authentications, this is drag and drop authentication designer. So if you wanna change in your application, you want to go from a social logging using Google, LinkedIn, Facebook, and you want to have a more high, high secure authentication mechanism like bank ID or something, you just drag and drop and you change the chain. And how we want this, this, this to to flow all the policies, you also here have full visual kind of control of as you can see in it. Or if you hate using a console, we actually using terraform so you can automate everything and have configurations done programmable so you don't have to click.
But from some of the data it's actually pretty nice to at least have some visual representation on how the different identities and edges and nodes are connected. And there's a simple, simple use case here that I'm will just show you and typically what happens in the beginning, if you have a registration or whatever and say you wanna have, I just want create a digital twin or the first identity in the platform and very often you yeah, you can use for instance Google login. When you do that first time, of course you will get your identity created, the unique identity and and what we pick up from that first step is actually just a few properties, mainly email the rest, first name, last name, the probably the only thing that has some level of insurance here is the email address because you probably need to have that confirmed as all of you guys know that you can, you can fake your first name and last name so it has much a lever, lower level of insurance, but at least you start it, you created kind of like your, your your first digital digital twin out there.
So how do you actually enrich this and reusing an in just engine that again, depending on the level of churn, you can start enhancing and building out the knowledge about all these identities. And if you, for instance after this say, you know what, I want to kind of like add my family members into the equation, just a lot of databases already that have that information that you can query but I don't want to do it or, or add that to my my identity before I have a higher level of assurance. So what we have done in the next phase here is that if you wanna connect that to your identity, I really would like to know who you are. So we're using biometrics and we're scanning your, your passport and as soon as you do that, you see a lot of stuff happening in in in your identity.
You have your still your identity there. Then on the right side you have, based on the information that we took from the chip in your passport, you have a lot of more information which is now have a higher level of assurance. And at the same time since we have this security level, we went out to an external database where we can actually finding the information about your household and your family and now you see also how the relationships and the metadata is is added. So you can see kind of like my, my my wife myself, we are kind of like part of the same household. I'm of course I'm a father to to to my kids and my wife is the model to the kid. But now you start seeing the relationships and the really powerful thing about this is that for making a decision, you don't necessarily need to have the data anymore.
I can just put a policy in there saying, knowing that I'm a father of specific kid, I know that he should never get access to my credit card even if I add my credit card to my, to my digital twin. So you, but you don't need the data. You can just say, you know, the relationships and then you can make a policy out of that, but actually not having the data itself. So just for making it even more fun, we could also very easily then start looking what are, what are stuff do I have attached to my identity in addition to the family? And again, there's a lot of decentralized database out there where you can look up vehicles based based on names because this is databases that people are using for, if you're trying to sell a car, you want to make sure that the owner of that car actually is owning the car that the guy that's going try to sell it to you. So if we ingest that information in, into the model,
See what happens. Ka we starting to get much, much more information and it's kind probably a little bit hard to, to see all, all the information, but now we can see to my property, in addition to have my family members map there, I can actually also see cars that the household have and which car is owned by by my wife. And again, you starting to building up a lot of knowledge that, that you can use for, for, for making even more fine-grained decisions. Then just the last thing that car maybe you are using that and you go to a grocery store and somebody owning that grocery store would like to offer you free parking if, if part of a loyalty program. So what we easily can do is just have a camera look on your license plate, do a real time look up, see who's actually owning this car based on license plate information. Then we can take that information and see is that person actually in a loyalty program? And if yes, open a gate and you will have free parking. So connecting all these identities together make really, really decisions in real time based on context. And this is what you just saw happened here and actually how this ends up in the knowledge graph in, in the backend.
So just ending this little kind of like look into our platform, what we kind of like do, it's, it's kind of like a holistic platform. We absolutely are looking at everything as first class citizens, the centralization. We can actually, if you get information from a database that already exists and a API or getting credentials from an SSI network, we don't care what it is because there are going to be web two and web three and they need to interact for very, very long time. And this knowledge of course is built up by learning where machine learning technologies come into play. So hope you got a little bit kind of like got little peak preview on what we're up to. And of course you guys know where to find me if you wanna, if you wanna know some more details. So maybe I hand it back to you, Richard.
All right, thank you Lai. We are going to move on to the question and answer portion of this webinar, but first let's go over the polls. So if we could bring the first poll up possible and we'll take a look at that. So the question was around, you know, what's, what's peaking your interest to join this webinar? And it looks like the majority is trying to understand some authorization trends and there's interest in the indite solution as well, so that that is as expected. So could we move on to the next poll and take a look at that as well.
So the type of authorization mechanisms being used in organizations we see quite a bit as using our back, which is expected, AAC is gaining popularity there and typically AAC also includes our back in it as well. So we have some all of the above in there, but we're also seeing some increase in relationship based access controls, which is, which is good. So with that, let's move on to the question and answer here. So if you could type in your questions at any time into the webinar control pain. So let's start out with this first question. What are other possibilities or things that you see customers using knowledge graphs for?
I think I already touched a little bit of that in in in one of one of the slides because as I kind of like we found out that having all this information, all all the data, knowing the relationships, depending on what task the knowledge graph for you can get different answers. So again, yeah, use it for getting kind of in all types of, for insights, you'd use it for recommendations, you can use it for personalization of course we can also really, really easy hook into some kind of like risk based system and using that as, as one of the things that we are making decision based on. So the, the opportunity here is, is endless, but I think the, the really, really powerful thing is that this is not a silo system that only do kind of one small thing of of of what you need for the entire use case from a customer. You can use the same information for a lot of different things that I just mentioned.
Okay, thank you for that. Looks like another question coming up excited to know about k a how would indicate support some of the on-prem systems?
So first of all, yeah we, we are cloud-only. So if honestly to be very blunt, if you need the technology OnPrem, we are not a solution for you. Of course if your OnPrem system can out again the way you are used to kind of like externalize authentication by calling out to a social provider or one of the identity guys out there like for work Okta, ping, whatever, the same way you actually should, this new application of services should be able to actually call out for also making an authorization decision. So just externalizing all of these things and this complexity to a service instead of again trying to it into your application.
Okay. It looks like there's a number of other questions coming in here. Let me just go down and I can get down there just a moment. Could you please clarify how you define the business logic based on knowledge to perform identity governance?
That I cannot answer. So I'll I'll hook you up with, with one of our architects that, that are looking, looking into that and how we actually are modeling this op in our, in just engine. So I don't have the details on it.
Next question. How do you address privacy concerns in this model like gdpr?
So first of all that that is one of the design principles that is kind of like was in there from day one that we need to, to apply to. I don't think you, and if you comply to gdpr you actually are doing really, really well from, from a privacy perspective. The first thing we do is, is kind of like we are we actually separating the identity graph with PII information from, from the, the knowledge graph that has more of the, the other type of metadata and, and the nodes. And of course all the information in the identity graph is, is kind of like using crypto. So we even, we can't go in there and actually see, see the information, who the different persons is and if the person decide to cut the, the relationships between some of the knowledge that that is been used for enriching and everything is, is, is gone. So, so we, we don't have control of this actually the end user have control by and all our p i information and if that your identity is connected to some of the other information in the, in the knowledge graph.
Okay. It looks like we had another question that came up just a moment. Looks like someone is asking about like, like who's, who's using indite now and what kind of use cases primarily on Siam? So consumer identity access management,
Where we, where we have most interest now is in and verticals like for instance retail that of course have that are, are would like to to build new applications and, and, and services and both were attracting new, new customers but also retention. So, so customers that have a big public consumer base that actually can see we can do a better job, we can grow our top line revenue. They are the, the first one our design partners, you know, people only buy for two reasons. It's either fair or greed. So either you kind of like you go into the use cases because you're looking from a compliance and risk, which of course is is very important, but if you can go in and you can help an enterprise and grow their top line revenue or have more happy customers, those use cases and those decisions goes much, much faster. So instead of going into like something heavy regulated like health industry, we see it's much, much quicker to get adoption and, and decisions on use our technology in, in for instance everything hospi, hospitality, retail stuff that had a lot of consumers that would like to really en enjoyed our customer base faster with new functionality.
Okay. The, the next questions I think you just answered that, the next question was, you know, which industries seem to be the most interested in this to type of relationship data? Yep. Yeah,
Knowing your customer is a really
Thing. Oh, go ahead, go ahead. I'm sorry to cut you off there.
Yeah, I said knowing your customer is a really good thing. That's where you can do some extra service and that that's all about what identity data, identity management is all about.
The next question is indicate a multi-tenant service.
That's an easy one.
Can I get more easy ones?
What instrumentation or enablement is required on the resource side in order to leverage K back offering? Like in,
Yeah, that's kind of very detailed questions but what we're trying to do, and this was a little bit about how you consume kind of like indicate either through, through our SD case or straight to, to our APIs. Of course if you're using RSD case then, then you have more of, of this instrumentation already in the SD case. So when you are interacting with the sdk, that could actually really easy to kind of like send information into a SIAM tool or, or whatever. So we're trying to build that logic into the sdk. So again, the developer can, can faster develop an application but also be able to feed security information in real time when the SDK is, is, is used to to order type of, of backend system. If you're using our APIs, you need to deal with a lot of that stuff yourself. You have a choice depending on how deep you want to go, but we, we put that instrumentation into our SD case to make it easier.
Okay. Looks like we're coming up towards the end. So the questions here, but one of the questions is, you know what, just a moment. I think that was the second part of the question is like for example, you know SaaS support per K back out of the box right now?
Yep. That's our, everything we do is SAS service or infrastructure as service and one of the functionality is is K back knowledge-based access control as a service. But that's like one of the, the things that we are, we are offering. So you can can grow and and add more functionality as as your use cases expense.
Okay. Two more questions here and we're kind of coming towards the end of the webinar. So how do you use machine learning at indite?
So first of all, I think I, I answer a little bit that already that we look at machine learning, it's something that we use kind of horizontal when we are building, building our, our, our technology and, and of course one of the big headaches when it gets a lot of customers or users or things is, is then the, the nightmare on handling policies. Cause you, you get, there's so much going on and your implementation gets so big. So what we're trying to use machine learning to is actually help with that headache. There's, it will not take over everything. You still need humans in there, but after a while you start learning which policies are being used, which policies are not being used, is the duplication into this could kind of like be do this smarter and then actually suggest changes and, and and also start with policies based on similar kind of like persons trying to do lot of the same thing.
So you don't start from scratch every time. You can see I've seen this pattern before, I've seen kind of 10,000 customers trying to do the exact same thing. Why don't I just suggest this policy? And it's probably kind of like much better than having human beings sitting there manually coming up with, with adding, adding a policy. So we're trying to make it easier for, for the security people, for system admin that gives, get some help. I think that's a good example of one of the places that we are having a lot of focus at the moment.
Okay, so we've come to the end of the question and answer session and we're coming to the end of the webinar. So thank you everyone for attending and in for LA for your, for your insights. Additional resources are available both on Cooper or Cole and websites. So thank you for attending and we'll see you later.
And thank you Richard for inviting me and have a good rest of your evening.
All right, thank you. Okay,