Good afternoon, ladies and frontman. Welcome to our equipping a call webinar, the future of data-centric security enforcing access control for relational and Hadoop pick data systems. This webinar is supported by axiomatic. The speakers today are me marked equipping around the principle Analyst at coping a call and the cherry Gable president at Matics Americas. Before we start some general information, some housekeeping information, keeping our calls, an Analyst company, we are providing enterprise it research advisory services, decision support, and networking for it. Professionals amongst these services. Also our events, we have a couple of upcoming events. One is or consumer identity summit, which will take place in Paris, France November. Then we will do the digital finance world in Frankfurt in March next year, and our main event, the European identity in cloud conference, which will be held again in Munich. Germany May 9th to 12th, 2017 would be glad to see you at one of these events, some guidelines for the webinar, you are muted centrally, so you don't have to mute or unmute yourself.
We are controlling these features. We are recording the webinar and the podcast recording will be able, will be available by tomorrow. And there will be a queue and a session at the end, but you can enter questions at any time at the right side of your screen. Usually there's a, they go through webinar control panel and there's an area questions. And in that area, you can answer the question so that we see them and then can pick them up. And the more questions, the more likely are Q and a B. So I'm looking forward to your questions, the agenda for today, split into three parts. The first part I will talk about in new thinking, future database security, getting a CRI on the data and only the database. So I will sort of lay the ground for what cherry Gable and will be talking about.
He look at the new version of Matics data access filter in depth and within that, and look at new capabilities, particularly also around managing access, controlling access to big data and had systems. And as I said, then we will do a Q a ATM. So many of you might know, copy a call, primarily Analyst company, which is focused on identity access management, even when our scope is, is broader. But basically when I look at this scope, identity access management is anyway important on database security. So the topic we are talking about is title linked to another topic we are talking about, which is dynamic or authorization management, or we sometimes also call it PS for adaptive policy based access management. So we are in fact, talking about two topics. One is a clear identity management topic. It's about how can I do authorization based on policies at runtime.
And the other is talking about database security and how could this technology enable us to do so to speak better? Database security database security is one of the many fields which are related to the I identity and access management field. So the right side, you see the identity and access management disciplines on the left side, you see major it disciplines. Many of them, it security, but not all of them. It security disciplines, which are related to that. And by the way, also the big data analytics and security governance, the bottom line in fact is one of the topics we will cover today. So it's really about this intersection of identity, the access in that case, authorization to the, so to speak the outer world. And when you look at security and how to do security, right, then I think one of the points, which is very important is we should, I think that's something I, I don't see if I'm honest, I don't see sufficiently, or I don't see often enough, which is where should we really start with security?
And what do we want to do? And interestingly, the term we are talking about very much is information security. So when we do security, our focus should be at securing information. And yes, that information held and systems. We are used to set access controls and systems to protect access to the systems, whatever else, but still at the core, the information, the information then delivered through networks and yes, network security is important, but it's not what we really want to protect. We protect our networks and our systems to protect information. The better we are in protecting information itself, the less we need to do or to achieve at the level of systems networks or the devices. And so, yes, we need all types of security, but from my perspective, the, the core of it, the information security, the real information security, how can we protect information better is still not, not enough in our, at our focus.
And what we are talking about today is also about at the end of the day, it's about putting information centric security, more into the focus. How can we really work here and look at what is happening with the data? How can we do this better by, by understanding which data to protect and which way even while we sometimes have to go a step way, step back and think about how can we implement it? And then some things have to be done at the network level, but with the focus far more on the information than in many other disciplines. So we, we are talking about topics which are called dynamic or sensation management or AP adaptive policy based access management. Or we also have the term of ABAC, the attribute based access control and all these are related and basically mapped to the same scene. What are we talking about?
We're talking about saying we have policies which make decisions based on attributes for attributes. And I've talked about this in a minute can be very different things, but basically the idea to say, we have that when we look at these systems we commonly have in administration, we have an area where we store the policies and all these are called policy, whatever points we make, the decisions we to do this, make these decisions. We might request information. So policy information from databases, directories from services, for instance, the context of a user. And we enforce these policies that can be done in various ways. So we can have a central policy enforcement point and, or a decentral policy enforcement points, which directed sit at the application level, or which sit in front of an application server or which sit in front of a gateway. So they are various ways we can construct our environment.
The policies are based on the attributes as very term comes from the attributes can be the attributes of the identity. There can be additional attributes we use, which are, for instance, provided back from the various applications. And then we can make decisions. And the smart thing was doing everything that way based on policies that we have one central set of policies. And if a policy changes, the change becomes effective immediately. So we don't have to change security settings and downstream applications, whatever else it's definitely far simpler because it's dynamic. And when we look at AAC, it's very frequently also seen in the context of AEX. So this is more or less, I have this discussion still quite frequently. Should we do RBK? So role based access control that's term or Abe attribute based access control. In fact, there's a continuum and you probably best do both.
So not the one or the other. And if a look at this continuum, so in a sort of pure role based world, we only would have roles which are used to manage the access in facts. There are other things such as constraints, and we frequently drive into factoring constraints into roles. So we have the sales man and we have the sales region, a B, C, D E F, and so on. And we end up with many roles, one per, we could also say we have a salesman and we have a constraint, which is the reach. And if you combine it in the policy at run time, it's far easier because we have less roles. We have the organizational structure, which that frequently is mapped into roles. We have the business activities. So what someone allowed to do in the process, which again, might go back to roll the context, which is really more dynamic.
So if the user uses a certain type of device, you might be allowed to do less than others, and this all ends then in the risk equation, we have. So depending on, on the context, depending on the constraints, someone's allowed to do something or not, there might also be other attributes. And so the more attributes we have, so to speak, the more we are on the AVAC side by roads, commonly are one of these attributes. So this is the bigger picture we are operating in. So from, so to speak poorly aback our back to perfectly AAC.
My belief is that the more stuff we can factor in the better we are and the more we are, the side of policies, the better we are. So what it's really about is about context and policies and making decisions based on the context, the way to use the car in the device, the, the network, the location, whatever else, and the policies, which is, and policies, I think is a very well known approach. So we are used to sing in policies. Martin Kuppinger is allowed to use that printer. That's a policy or Martin Kuppinger is not allowed to use that printer again, a policy. So we can use it in a very well standardized way. They are well understood by business. If we do it right, we don't need to transform it to it. Language, it's a uniform way to define policies also at various levels.
So we can sort of the same abstraction of a policy can be used at very different levels. So if you say a subject is allowed or not allowed to do something, we might say, Martin Kuppinger is allowed to use the printer or a packet from that IP address is allowed to pass the firewall very different levels. But basically if you look at the, the structure of such a policy, it's me, same. So, and as I said, I like the term adaptive policy based access management for that, because it's about the adaptiveness of access. And it's about a policy based access. Maybe then look at the database security, which was the core topic of today. What is the reality of database security security today, a user, and we have web server, an application server database. So the user indicate somewhere, yes, we know Martin equipping are, is accessing the application server, but then we use a technical user account to access the database and get some code back.
And then we use some co get some results sets back, and then we use the code code to analyze these results sets. So what, what really is happening here? So to speak a coded authorization, and if you do it in code, it's obviously not a very good idea because changing the way we authorize means changing the code. But I see still a lot of such applications, which really doesn't manual through the results. That's yeah, we have to have different database security, but overall it's not a very smooth way to do it. And that's, if you're honest, the reality of many, many database based applications. So what would happen if you apply AP to database security? We have the user who also indicates wherever web server application server. We have the code as well. Clearly there is code of the application server because we have an application of the application server, but this code at the run time uses our system and asks this, this user allowed to do it.
We could also do it here, so we could hear, say, okay, what is the user allowed to do? We could have it at the database and saying, the database knows the user and ask in a policy, which results can I give back? Or we could do it on the wire if we take the SQL statement and modify based on the policy. So there are various ways to do it. Ideally programmers work that way. Ideally software developers for customer of, to shelf applications and particular developers of every cloud service work that way. But the ideal world far away in that. So we rarely see databases and, and, and cloud service and applications, which really support the API or dynamic authorization management. So doing it on the yr might be the workaround we have because we know particularly the database where there are certain types of statements which comes through and that's the way where we can then access.
We still can use an additional database security to encryption all that stuff, but we can get rid of the coded or authorization. So that from my perspective makes a lot of sense. And then Cherryville dive far deeper into detail in his part of the presentation, but basically that's the way we should sing don't code security, call external systems. That's the far better way to do it. So what about data be data security? And I think it's one of the biggest challenges today that we have some, some control some experience when it comes to traditional databases, but what about big data? So when you look at the reality, the reality is really a nightmare because we have little control about access to the data sources about the data processing and the results that's for instance, the cubes. So at none of these levels, we have a good, really good approach for security.
We don't really know what happens if someone is allowed to do certain things, will he end up in combining data where the result might be far more critical than the input data? So again, what could we do? We could do it on the wire. So potentially the same approach as with databases might be huge, might be used. We could do it in the code and quote us in the code. In the sense of, if we have some applications, we can call out to policy systems and we have the technology, the standards, the standard, the end of today, exact or openness in the applications, the tools might support it. However, again, the challenges that the, the, the vendors in that space for big data usually don't have to support. So we will find out, need to find out ways. And one of the ways to do it is what the cherry will talk about in his part of the presentation.
So what are the benefits and challenges? The limitations, the obvious benefit is we are externalizing security. We are replacing coded security, and we have all the advantages of a, of what I call adaptive policy based access management. So if we change policy becomes effectively, immediately, it's a lean way to, to, to create applications. We, we are very flexible in what we describe. We can have the business describing the policies, all that stuff, the challenges. So there's one challenge, which is sometimes only perceived challenge of performance, but at the other day, at other end, you know, you have to do a security check anyway. So whether you do it in, in your code or let it be done by a standard service, natural model is better because the developers of such standard tools clearly can focus far more on many challenges than then when you write a piece of code, once the intrusiveness, it depends on the approach, but I've quickly outlined a couple of approaches and siloed organizations have to agree on one approach.
I think that's probably the biggest challenge so that you have organizations and you have to developers, you have to security people, and you have potentially a lot of other people in the business, cetera, and you have to find the, find a agreement that this approaches the better one. Clearly, if we do it here, it doesn't cover all aspects of database, securities, or applying. These approaches. Dynamic authorization to databases will not cover all aspects of database security, but we can use the other tools as well. So the encryption or whatever stuff, depending on the approach, it might be restricted to specific database systems. That's also one of the challenges, but overall, I think there's a very good launching and saying, Hey, why, why not doing it better? And unless the database, so the developers of the database systems and the big data solutions, don't support it out of the box. Let's at least find a way to do it anyway by so to speak, attracting the communication or even better doing it in our code. We are creating at the application server level with that to go more into detail. I hand over to cherry who will talk about the new version of X Matics data access filter in depth. So cherry, I make it a moderator, and then you can start, okay,
Well, Martin, thanks for making that introductory presentation. I think it really lays a great foundation for how we'll we'll continue the conversation. And what I like to do is to speak for a few moments about some of the larger business and technology trends that are are happening, because I think we always have to think about, at least from axiomatic perspective, think about authorization and access control and security in the context of some of these trends that are happening around us. And then I'll go quickly into talking about the data security solutions that we're we're speaking about today. So certainly on the business side, one of the key factors we, we see that impacts move to big data, for example, is the need to reduce costs. You know, that's a continuing pressure on, on both it and business departments is to reduce costs. And then as well, the compliance and regulation environment continues to evolve and change.
GDPR is one of the major ones that's happening over the next couple of years. For example, there's also this notion. I, I want to be able to access any of my data from any device at any time from anywhere. You know, how, how do we address these kinds of business demands from a security perspective, of course, a big data and analytics. You you've mentioned this Martin, you know, when we're combining different kinds of data sources to get new value from that data, how are we addressing some of the security or, or privacy concerns from that approach? And then I, I think an overlay concept that we hear a lot about is this notion of digital transformation, you know, can we make the customer experience so much better than it is today? You know, removing the friction from different kinds of transactions or, or allowing customers, partners, and others access to their data like we've never done before.
So that's just a few of the business trends. And then on the technology side, we have the usual collection of buzzwords. Some of them have been around us for a while, you know, cloud of course, mobile first kinds of approaches, big data DevOps, you know, the notion of continuous deployment of applications, which myself being from a banking background previously, the idea that we're going to continuously change production applications is a certain, a foreign, certainly a foreign concept to, to many of us. But it's certainly a trend that we see evolving. And a lot of that is driven around an API and microservice approach. You know, this is, this is often the way we want to build applications today, even to expose information within a big data system is, you know, likely through API and microservices. And then we have IOT or the internet of things.
One of the, the trends, that's a big contributor to all, all of the data we are we're collecting in, in big data systems. So this is, you know, part of our challenge here is also to not necessarily think about each of these technology trends in isolation, but the, the mashups that likely occur with combinations of them. And if we look at the, the data base world for a moment here, what I often hear from organizations is that they want to move from this model where with many legacy applications, you have the typical architecture Martin that you described earlier. You know, you have a, maybe a web application, an application server, and it's hardwired to a particular database, and you have a lot of the security or access rules in the code of that particular application. And this has a number of consequences. Of course it means if I need to access that data, well, I also need to have access to that application and be in the right role or other entitlements.
But it also means that I have, you know, I have to manage all of these applications and databases individually. So that's, that's certainly, you know, a cost factor and a security challenge. Now, when we start moving these of this data to a consolidated model, whether that's a data warehouse using traditional relational content, I'm sorry, relational database containers, or if it's to a big data system like Hadoop in either case, the question becomes, okay, now, where do we put the security? You know, cuz now we have many applications potentially accessing a consolidated source of data, but we've removed all of the security from what used to be within each application. So that's one of the challenges that we face when moving to these consolidated data models. So how do, how does Matics address this? Well, we do break the, the challenge up into different areas. One is the focusing on the authorization bottle for the applications themselves.
So this is in the business logic or the middleware area, you know, using APIs, web services, microservices, and so on. And then we have a separate line for authorization for databases, historically it was for relational database content. And actually today we're announcing our, our big data security solution for systems. And then we have a third category products for analyzing these access policies. So if we're centralizing the authorization logic in the policies and rules, we also want to be able to do proper reporting and analysis of those policies to, to certify that access is properly configured.
And as similar to the diagram that Martin used, you know, you can implement this externalized and dynamic authorization in different places within the application today, we're focusing more on the database level here where we're dealing with relational databases and, and big data systems. So applying the same concepts of attribute and policy based models right down to the database level. And it's interesting Martin that we, we do hear some customers starting to talk about this, what you called security at the core, you know, right at the information. And this is particularly useful when you now have many applications using these consolidated data systems. So you can actually get a lot more leverage from your dynamic authorization implementation because you can cover so many applications through this model. And for those of you that are not familiar, the way we approach data centric security for relational databases is this model here.
I think Martin, you called it the, the APM on the wire. So in this case, there's a, a proxy model that intercepts SQL statements that are sent to the database. And this, the system calls out to an authorization engine that's specialized in SQL and it can analyze the policies cuz now we have, instead of policies in the code, we can have policies that say, well, who can access certain tables? And then within those tables for columns that are deemed to be sensitive or, or important, you can apply additional policies and rules to those columns and the authorization engine can inspect other attributes about the user, about the data and other context to ultimately modify the sequel where you have now implemented your, your access rules. The modified sequel is executed by the database and now only authorized data is sent back to the application. So you don't have to post process the data to further redact it or mask it.
It all can be, excuse me, it all can be filtered and dynamically masked within one operation here. So it's a very powerful model. Now we think there's a number of important capabilities here as Martin Martin was saying, you know, the context awareness is really a, a very powerful concept here to be able to implement from a centrally managed system. So there's certainly that it's also applicable to multiple vendor databases. So it's not just isolated to a single vendor solution. And as I mentioned, you can do Dyna dynamic data masking and filtering it in one operation here. So you, you cover a lot of capability and then it's over time, we've added additional functionality to support multiple SQL functions. So we started with select and then over time as the new versions of the product have come out, we've added update, insert, delete, you know, we've added additional databases over time and we will add for other database support as customer demand warrants. And we do that by simply certifying that the sequel dialect of that particular vendor is supported in, in the product.
So what about big data? I, I think Martin, you laid out some interesting business cases for applying AAC principles to database and, and to big data as well. And it's, it's some of the same concepts, right? That we can centrally manage these access rules instead of hard, coding it into the application or into more stored procedures or other similar code constructs. We also have to understand that the, the big data world is now introducing new challenges to us, you know, and that is the diversity of the kind of data that can be added to these systems and how that can re result in specifically security or privacy concerns. Because now we are, we are co-locating data that previously was managed individually and we're seeing similar to some of the challenges in, into the relational database world that just having course level table or column level access controls is clearly not enough in, in many use cases and scenarios.
So we've, we've introduced a, a new product that we're calling smart guard for big data where we're applying some of this, you know, some of the same aback principles to Hadoop big data systems, but using a sequel on Hado approach. So it's, it's still a transitionary method here, if you will. So we're not going to a pure, no sequel implementation in the first version, but using the SQL Ondo model, that's still quite popular. So in this way, we're able to address some of those privacy or, or security challenges and requirements when we're protecting critical assets, dealing with compliance requirements and so on. And so we, we think we can provide a lot of very important and key functionality, you know, applying this dynamic authorization model now to, to big data systems implementing filtering masking and so on just as we can for the SQL based systems.
So how does it work? What's actually quite similar to how the, the relational database system works. Although instead of having a, on the wire proxy, we have, you know, a driver or a interceptor agent that's on the application and Nicole's a sequel transformer, but otherwise the concepts are the same. You know, the, the attempted access to Hadoop is intercepted sent to this SQL transformer service that applies all of the, the filtering and masking policies to the request, which is then sent back to the application, which executes the updated statement. And now only the data that adheres to those constraints is sent back to the application straight from the Hudu system. So similar, similar model to what we've described previously. And so in, in this way, excuse me, when we see organizations shifting to this data warehousing model or data lakes, and so on, now you can, you can apply this essentially managed aback and dynamic authorization service in front of your systems with the smart guard solution, but also in front of data warehouses with the amatic data access filter solution to give you that centrally managed control of the policies for your information or for your data directly.
So some of the important features here just to reiterate, so we're, we're, we're automating the modification of SQL based on this centrally managed service so that you can apply the policy based filtering and masking. So we can remove those, that sensitive data credit card numbers, social security, numbers, health diagnoses, and so on, and only allow certain users that have the proper authority to access that sensitive data, but give them open access to other information that they are authorized to. It can even be used in conjunction with things like encryption so that you can, for example, decrypt certain fields based again, based on policy. So it's a quite a complimentary approach to some of those other database security concepts and technologies that Martin mentioned. So now we're able to enable fine green authorization for, for big data systems utilize all of the additional context from, from other attribute sources.
And that's a core feature of an aback system, and there's also the policy standard behind us. You know, we to use the, the exact Mo policy format in, in the background. So you still have, you know, the industry standards based policy format for that. So that's the end of my formal comments. We also have another webinar that we're doing next week that you can join us on. We have both times for convenient that are for communion for Europe and us audiences and Martin. I think we can turn it back to you to do some, some Q and a. And I look, look forward to some of the questions from our audience.
Thank, thank you, cherry. And I'll take back the moderator role and we directly can start with the Q and a. So as you can see here, the Q and a right now as the next part, we will look at it. We already have a couple of questions here. So if you have first questions, don't hesitate to enter your questions and they go to webinar control panel in the area questions so that we can pick them. So there's one question, which that's, what are the top enterprise solutions for realizing AP or adaptive policy based access management, dynamic authorization management, and how intrusive is implementing this to the application? So maybe I'll, I'll pick it first because it's was a question which came during my presentation and this for your body, the, the, the Analyst Analyst question about the application. So when I go back to our leadership compass, we did on this, I think the year before I think X geomatics overall was one of the, the clear leaders.
And there are a couple of other players in there. I don't want to mention that that these is them, but we have a leadership compass on that. So our leadership compass is sort of our market segment, comparison of vendors and their solutions. And we have done one on this segment. We call it dynamic oration management back then, where you will find that information. The second part of the question, and that's really when charity wants to step in how intrusive is implementing this to the application at the end, you need to call out from the application. So it's the difference between coded security and non coded security. If you look at an, at an existing application, clearly it means changing code at the end of the day. In some way, if you look at at, or, or you, you added somewhere the wire, etcetera. So when you look at, for instance, database part, you can, there are ways to do it even without touching the application for many scenarios, it's about programming to a certain way of doing the authorization. However, if you compare this to coding your security, obviously it's the better way to use standard calls out of the application. It's far easier, less security risk, clearly the better way.
Yeah, Jerry.
Yeah. Well, Martin, I was thinking you could create a continuum slide for this as well, because you know, there are approaches that are very intrusive as you described, you know, when you actually change the application code and other approaches that are not intrus intrusive at all, if you can implement on the wire, the database model is one example of doing that on the wire, but also you can think of an API gateway as another example. So you can use the API gateway as the enforcement point. And, and from there, it's, it's just a matter of configuring the, the API gateway security policy to, to implement the, the dynamic authorization for those API calls. So it becomes more of a configuration exercise rather than a code management exercise. And we always look for those approaches that are less intrusive to the application, although you, for, for organizations that have critical applications, that just need to be retrofitted because they've had, you know, audit issues for some time, then we, we see where organizations will often create their own internal API. So they have their own code that developers can call, so that it's independent of any vendors' implementation. So that gives them all, both the advantages of managing the security externally, but also some vendor independence so that they can control that, that API that developers use internally.
Yep. Okay. I have another question here. So instead of rejecting a sequel query that is not fully authorized proxy decisions is proxy decision is to return what is possible? Is there an indication that there was an error reduction of data and how is this error handling managed, right. Sure.
Yeah. So in our implementation, the SQL request is never rejected per se. So it's not like a permit deny. Rather if, for example, I wanna do a select star from a customer table. And if I am not authorized to access that table, I will just get zero records back because within the SQL protocol, you don't have the notion of sending a separate error message back to the application. But if I am authorized to see, you know, customers in my region, then those records and all the appropriate columns will be sent back to my application, whether that's, you know, an Excel spreadsheet, it could even be, or it's some kind of business intelligence tool, you know, the records and the columns that are authorized will be sent back. And this isn't also an important distinction that you don't want to break the application. You know, if it is expecting four columns, I will send back all four columns. Although some of that data may be redacted so that the application still functions properly.
Okay. Thank you. Another question, how is AAC integrated into the software development lifecycle?
Well, I think you touched on this as well, Martin, it, it, it is not always the case where that's incorporated into the SD L C, but I think there's, you know, this has to be instituted by the particular organization, you know, how do they approach security generally, and then to ensure that authorization is managed as part of that. So for example, how do they deal with authentication today? How, how do they deal with database encryption? You know, how do they deal with communication securities when they're building applications? So I, I suggest that authorization has to be one other element on that list of, of how to approach that. So there would be services that handle authentication, for example, whether that's done by, by the organization or if it's outsourced to a, you know, a third party identity provider or the partner. So that, that has to be incorporated in there. Would you agree with that, Martin?
Yes, I think so. As I've said, from my perspective, an important aspect is clearly always the silo silo aspect. So I think incorporating is the one thing, the other thing is really create an organization that works for, for modern security and, and that means getting rid of silos.
Well, that's a huge, that's a
Huge, that's a huge
Challenge. Yeah. Yes. It's not a technology challenge as much as it is really a culture challenge for organizations,
But I think it's a good idea to Des it organizations anyway, particularly the days of the children transformation, where more and more of it and more and more securities moving into the business and developing the things and developing the devices, all that stuff, developing the apps. And so I think having still these traditional silos doesn't help us in the transformation anyway,
That's certainly true. You know, we have to break down those barriers absolutely. To really get the benefits of a digital transformation project.
Okay. Another question I have here is can the policies be used to secure any type of data and SQL?
Well, the general answer is yes, because within SQL, you know, you have a fairly defined context, right? Because you have this, the, the tables, you have the schema of the tables. So it's a clearly defined environment. And then within SQL you only have a limited set of commands, you know, select insert, update, delete, for example. So in, in that way, it's, it's a very constrained environment, but you have the full capability to manage any kind of data. Also, for example, you can use the value within a particular cell in the policy. So you can have a rule that says certain medical medical conditions can only be viewed by personnel that are authorized, you know, a, a specialist doctor or a researcher, or in financial services. You know, managers can see values of client account portfolios that are over 1 million euros, for example, but, you know, junior bankers cannot. So you can use even the value of the data in the policy. So it's, it's quite a powerful model.
Okay. Another question, what types of projects or use cases require an ABAC approach to data security?
Hmm. We, we often see projects that are using business intelligence or business analytics tools to implement this kind of approach where you can centrally manage the authorization rules. One, one example comes to mind where a customer was using and was three or four or five different off the shelf BI tools. And as you know, Martin, as you were describing, each of them has their own security framework and security model. And it was very difficult for the company to consistently implement their security rules across all of those BI commercial products. And in in fact, their internal auditors were citing them for having issues with potentially exposing customer data, you know, too much customer data. So they implemented this dynamic authorization model at the database. So now, whatever off the shelf tool calls to the database, they know that only the authorized data can be sent back. So I think these kind of business analytics, business intelligence scenarios are, are quite a common one for implementing this kind of approach, probably the most common.
Okay, great. So the last question I currently have here is, so if you have more questions, please end them. Now, the last question I have here is where does smart guard fall on the R aback continuum?
Yeah, I, I I've said this before. I really like that slide that you use
Oops
Roles and, and aback approaches. And I think where the smart guard and, and the database filtering approaches fit is probably around the context area. You know, so we're definitely shifting mostly to the aback side of that continuum because you can, you can incorporate, you know, the context of the user things like their location, their device, their department, their relation to the data. So it's definitely implementing an aback approach, you know, not necessarily incorporating the, you know, the risk metrics, although that, you know, that could be a part of the equation as well, but, but definitely toward the aback end of that continuum is, is definitely what we were talking about here.
Okay, great. It looks like we have answered all the questions, so thank you very much, Jerry. Thank you very much to all the attendees for listening to this coping or call webinar. Thank you, formatics and supporting this webinar and have a nice day.
Thank you Martin. Thanks everyone.
