Beyond Database Security: Adaptive, Policy-Based Access Control for Dynamic Data Filtering and Data Masking

Good afternoon, ladies and gentlemen, welcome to our equipping a call webinar beyond database security, adaptive policy based access control for dynamic data filtering and data masking. This webinar is supported by axiomatic. The speakers today are me Martin Ko around principle Analyst at a call and drier who is product manager at axiomatic. Before we start some information, copy a call or some housekeeping information, and then with direct level dive presentations.

So keeping a calls, an Analyst company, providing enterprise it research advice for services, decision support, and networking for it. Professionals who do research advisory. And we do events. Our events include the, an event in Australia plan for November and our European Atlantic cloud and cloud conference, which will be held next time May, 2016 in Munich. It's the leading event around these issues in Europe and you shouldn't miss it. There are other events such as webinars and seminars and so on more forthcoming events. So have a look at our events, website guidelines for the webinar.

You are muted centrally, so you don't have to mute or unmute yourself via controlling. These features. We will record the webinar and we'll make the recording available latest, but tomorrow and the Q and a session will be at the end of the webinar, but you can answer questions at any time using the questions feature in the go to webinar control panel. The more questions, the more interesting the Q and a. So let's have a look at the agenda. The agenda is usual split into three parts. And the first part, I will talk about the new thinking.

So database security based on adaptive policy based access management, the benefits, challenges, and limitations. I also will sort of set the scene for the entire presentations talking about what is a and AP and what is behind us and what causes these changes than the need, and then move to the database security specific aspects of that. And the second part of our webinar, Dr. Naer will talk about dynamic data filtering and masking use cases, solutions, performance considerations. And then finally we we'll do, as I already set, we'll do the Q and a a session.

So when I look at what is happening in these days, I think one of the challenges every organization is facing. And in fact, also we are facing in our personal life is that people are increasingly connected. Organizations are increasingly connected devices and things. So we have quite complex relationships here, which are getting more and more complex organizations. People are part of organizations or people act on behalf of organizations, organizations might own some devices. They might communicate with other devices.

People might own devices, and then we have to sing in and all that type of stuff. And we need to, to manage access. We need to keep control about information in this ever increasing environment with far more players in far more different, let's call it Invos roles or in personas or whatever. And this really makes things more complex. And one of the important things is how can we manage access to information of all these various entities with their identities? And one element of this is how can we manage access to database is how can we secure information?

And part of the, the story, the topic we are talking today is clearly related and, and growing an impact and, and the relevance based on these changes we are facing here. So, and clearly it's not only about humans accessing information, but it's also increasingly more about system to system communication. So you might have seen this picture before, where we talk about is fundamental changes of cloud computing, social computing, mobile computing, extending the scope of information security.

And beyond that, what we really see is that we really see this picture in the background of already shown and the fact that device, organization services, these are communicating, we, we see each other based on APIs. So application programming interfaces, and we need to get a grip on that. And so this is sort of the, the, the preface for what I will talk about. And one of these things is how can we really manage access in this increasingly complex world in particular, when it comes to access to databases?

So this is, I will narrow down sort of the scope right now down to the specific database topic, but I want to start with a term. So there's the common term, which is AAC, Ari based access control, which relies from its concept on a flexible set of attributes. And what happens here in the concept of airbag authorization decisions are based on policies that are made at run time.

So what, what effect happens is that we have on policy administration point, which stores policy at some point, which then can be accessed by a so called policy decision point, which builds on the policies and on additional information. And then we have the enforcement. So the policy enforcement point, which allows them to interact with a particular application or service. So this is the basic picture of how this architecture works like.

So we have central policies, we access information at runtime and the decision about if someone is allowed or not as externalized from the application and made in the central environment, there are various ways to do it. So policy enforcement points can be more centralized. They can be decentral. As I've said, there are various approaches to do that. They can sit on an application server, they can sit on a gateway, different ways to do it.

But basically the idea is to externalize the authorization decision out of the application, and to ensure that we can rely on a central set of policy across a broad set of applications, which then access information from various sources, which can be databases, directories, and other types of systems. So this is the basic picture here. Policies are based on attributes. We have the attributes of the identity, and we have additional attributes here, which we can use to make our decisions at runtime.

So occasionally there's sort of a, how should I say they're sort of an constantly constructive within Arabic, the role best access control AAC is attribute best access control. So where we have to roles. And then we have constraints. We have organizational structure information, we have business activities. We have the context of people. We have the risk, we have a lot of stuff and other attributes, but if you look at this, then the role is one attribute. There are other attributes which might constrain the impact or the scope of a role there's information about organizational structures.

There might be information about business activities, the context, the risk, and other things. So from sort of purely Arabic to perfectly, this is more sort of a continuum. And I think not that the, I don't think that the attribute is the important difference between the two of us. What really makes a difference, our aspects, our in fact, it's something which is not really policy based. It might be that policies are abstracted into roles, but basically it's not policy based aback and contrast is policy based.

And that also means that policy changes an aback automatically or immediately become effective while in an our environment, they need to be transformed into entitlements and push the target systems. Abe, conceptually is something which needs support from the applications.

It can be, as I've said before, it can be interfaced in various ways. There are different approaches to do that. What a is sort of mental little intrusive that's advantage, but on the other hand, a they can do more. It can work on sort of every type of attribute. And this allows to support a far broader range of use cases, which becomes increasingly important in the world. Like I've described at the beginning, this connected world where we can't manage everything by roles, because it's not only the humans anymore.

It are far more complex, far more rapidly changing relations and, and environments we are facing here. So we also have done conversation decisions, which in fact, in the AIC world are done centrally by the AIC system where PPPs the policy enforcement points might be distributed, but the system itself sort of provides centralized approach and authorization, relying on centrally managed policies. So Abe is in fact, more dynamic because changes in policies are in first dynamically instead of transferring them into static entitlements. This is really where this comes from.

And so we, as a career call, we tend to talk about P for adaptive policy based access management, because this adaptiveness to various types of attributes, the context, the risk roles, whatever the adaptiveness to that, and relying on policies are what, from our perspective, really sort of forms the center of this approach from our perspective, such approach such ASIC or API. However, you'd like to name it as a central element and application security infrastructure. And I'm preaching this for many, many years.

I think I've wrote a problem on this back in 2007, around application security infrastructure, which is about externalizing security out of the code out of the applications, relying on standardized infrastructure. So we have, and doing it for all for a administration application, authorization auditing, but also other security requirements. So encryption signing the technical logging, interfacing to enterprise risk management systems, whatever you can imagine.

So that's the IM IHG identity, access management and governance and more service layer providing and technical infrastructure, a set of services such as administration authentication and so on, and clearly authorization services. And for all of that, many of that, we have protocols and it allows us if we work with such a layer and the protocols to build applications where we don't care about security within the application, but where we externalize application from the security, so that we can change our service, we can modify our service, we can improve things.

We can manage things centrally out of the application instead of having coded or hard coded security, which is something we should avoid. So application security infrastructures building on a central type of infrastructure and very important thing. And this is where we should think about, and this is where also this idea of moving database security out of the database and out of the application accessing the database to central infrastructure makes a lot of sense. So this entire APM or adaptive policy based access management is really about context and policies. I've talked about it.

So depending on the context and other things, we need to be adaptive, decisions will differ and we can do a lot based on that. And policies are really the thing which help us to describe everything.

Every, everyone is easily able to describe the policies. So easy, simple to do. We can really easily work at that. So this is something which is quite, quite simplistic to do. And we see in the various areas and one of the most important area.

In fact, before I directly move to the specific database issues is adaptive, authentication and authorization. So we have an authentication system. We have an authorization system, we have our identity, our context credentials and whatever type of identity information, but we have our policies, which then might say, you need a better authentication to do, to perform the task. You have authorization policies, which say, okay, based on that context, you might not be allowed to perform that transaction, or you are allowed to do it, whatever.

And the application, in fact, requests, your authorization, there's a response of theorization system. And then the application can make its decision first.

And all, we have this basic idea of adaptive access, which in fact does us. At some point we have more and more information from external systems, also a run time. So access intelligence, looking at risks, user behavior analytics, looking at anomalies, and this adaptive access management, this is authentication or authorization. So context and policies will us allow to become far better and far secure in our applications, but only when we externalize it. And one of the logical points to start this database security. So let's have a look at the reality of database security today.

What is the reality of database security today? So we have this sort of application quite commonly. It might look a little different, but this is still a very common concept. So we have user accessing a web server than the applications are than the database. Okay. That might also the user using an app to access a service don't care. The picture remains the same for when we look at the essential part of what we talk about in this webinar. So we have to indication of the web server. It's done passed over to the application server.

That's usually then unfortunately, between the application server and the database, the authentication isn't passed further, but we use a technical functional account, whatever you'd like to call it, shared account to access the database, to return information. And then we have some code, which we use to define which information is provided back to the user. So we use coded authorization here, and we have a lot of security built into the code in these applications, running on the application server. This is a quite common, quite typical scenario.

We then have quite separately or fully separately, in fact, additional database security over here, where we say, okay, we have a database firewall and look at other things and we do some encryption stuff and blah, blah, blah. But the essential problem obviously is that we have code here and we do security logic within the code, which is hard to audit, which is hard to manage to change cetera. It's problem, coded security is a challenge and we should avoid doing it. So basically the idea would be how can we move authorization to an open system for applications accessing databases?

So how to apply to database security again, the same picture I just made this error a little longer here to put in some more stuff. So we have to user in the web server or use the app and this applications, server, whatever we do, some authentication somewhere we have to code. We still will need code clearly for the application, but the code, if it comes to authorization, might just reach out to our AP system, to the P P the policy first point, we have somewhere and request an authorization.

So, so we might do it at the level of the application server, which would mean that the code has been, has to be built in that way. Also the database, at least as long as it has a context of a user might do that. So the database might be sort of enabled for, for attribute, for adaptive policy based access management for, for AAC, for dynamic or sales or authorization management, whatever term you want to, to, to use here. So the database itself might be enabled, or we do it sort of as APM on the wire.

So looking at what happens at the network, defacing it in some way, gateway, whatever type of approach or something, which is listening or, or filtering, or, or gateway, whatever happens on the network here. So there are various ways to do it and saying, okay, theorization logic. And then the filtering based on these sort of decisions, whatever has to happen here, encryption, ization, whatever you could imagine that's done based on this decision of an external system, clearly there are some challenges around it.

So you still might have add database security there, some of challenges, but there are obvious benefits. So what are the benefits? One is we are replacing coded security.

In fact, this is a very major advantage. We have all advantages of AP in fact, so everything which is beneficial to the adaptive policy based access management or something we can benefit when we do it for databases specifically, there are some challenges which might come to your mind. So one perceived challenge is performance. So you have to track security, but honestly, security checks have to happen.

Anyway, if you have coded security, also, you have something where you do this security checks and potentially a system focused on doing that as a standard application, a custom of the shelf type of software might do that far better than what is coded by someone who in fact is not a security guy, but just does it as a add-on as an after source to his application. Intrusiveness depends on the approach that something where the naive will talk about more detail, silo organizations have to agree on one approach. This is clearly a challenge.

So the siloed organizations, the problem is we have database people and we have the identity and access people in the security people. We have the developers in, and all of them have to find a way to work together, depending on the approach. In some cases are less people, less so silos, so to speak in AUM limitations. Clearly it's not a full replacement for database security. There are areas and database security, which are not covered by that, but that's not the plan. It's about, it's about saying this is a specific use case. And then we have other areas of database security.

So SQL intraction filtering encryption, etcetera, which is done separately, depending on the approach. It also might be restricted to specific database systems. One last slide, before I move over to Dr. Naer how to make app reality. So since you should look at, get rid of silos, that would be the best thing to do, but it's a long term stuff. So break the barriers between the various silos, reorganize, nice your it, but you can do a lot of stuff without reorganization organizing your it. But if people start to speak with each other, definitely helps define guidelines.

So set guidelines for application architecture, development, procurement first, then we define gates near processes, or do it also for the database area, simplify the use, but the tools are far easier than they ever have been. So six are really going forward, build the infrastructure. You have a lot of this already, so it's really of making better use of it becoming more service driven and finally support transition. So how can you integrate it? And this is also one of the areas Dr. Right now we'll touch. So I'm done with my sort of introductory presentations.

I will hand over right now to switch NA year who will do the second part of the presentation, hand over presentations, your turn. Thank you. Thank you, Martin.

And, and let me just start with my slides. So you should be able to see my slides as well. And thank you, Mr.

Co, for a very introductory, a very nice overview of the challenges associated with the traditional models of back, how we move towards AAC and the, the whole concept of AAC and AP that has been laid out in great detail. And the, the fact Mr. Kuppinger mentioned about how moving away from purely data-centric security in the database to a more holistic picture is what I'm going to take forward in my presentation slides as well.

And it concentrates mostly on the policy based authorization and database security aspects, where you tried to connect the dots in your information security landscape and the product manager at axiomatic. We basically are a company that provides next generation access control technologies that allows you to make author system decision. So access control decisions on data based on multiple factors. For example, this is just to continue with what Mr.

Kogan mentioned, the, the aspects of who can access information and what, what information can they access and when can that access be given and where can that access information from, for example, the multiple channels that we will talk about in a slide or two, and how, for which devices, which APIs, which data, which mobile devices that you can access from and why, because that's what the it policies are mostly about. Why do you want access this specific information and not that specific information and things around that areas.

So all that is done using the concept of attribute based access control, aback, and specifically using what's called the extensible access control market language, the exact standard, which is a standard produced by a body called Oasis, the same body, which is in charge of the Sam standard and so on.

So if you look at the, the, the landscape of the it infrastructure and the, the it policies and, and the, the way it systems are accessed, you will see that in olden days, well, not too old a day, but recent past, at least you've almost always had this one-on-one mapping between the user interface, the application and the application and the database.

And of course you will have multiple users, maybe multiple applications using the same database for different reasons, but you kind of have this one-on-one mapping, which made life a bit easy because you could write tightly control policies that usually doesn't change, not too many variables. You kind of knew who was accessing it from where, but in this day and age, you have so many different venues and channels of access. You could access it from your mobile device, you're from your laptop within your network, outside your network from a cloud system.

If you have a virtual machine over there and so on and so forth, you could do that using APIs, you could do that using native applications and so on. So what you see is that there is a whole lot of area that is exploring in terms of the, the possible competitions and combinations that the it policy needs to kind of expand to care for that as well, because at the end of it, the, the, the main idea behind these policies and the regulatory frameworks and compliance requirements is to make sure that the data that's available for access is protected at the end of it.

So if you look at the product categorization, if you look at it from a pure product point of view, we used to have silos of identity management and access management systems, which does the who, what, where when by, and how that we just mentioned, and the other silo of the data centric security, which was more of to do with encryption masking redaction. And then you could tweak particular roles in a table to master the values or to call out user defined functions. And so on that could allow you to do some sense of control over the data.

And that used to be what was the data-centric security model, but more and more, when we talk to customers, we see the need for an emerge between these two silos into a centralized policy driven framework, which can handle both these different aspects of access control, both the access control about the, what, why, where, but specifically moving that away from pure application access control towards data centric, access control as well.

So you have the central authorization service, which I'll talk about a bit more in detail soon, which is able to handle both the identity access management traditionally, and the data centric security part of the traditionally again, using the concept of a that Mr. Hoping has mentioned previously. So from a D based centric world. So for people who have been involved in the database centric security aspects that are three main kind of sets, let's call it.

The one is the, that the database activity monitoring part, where you look at the database and look at the activities, find out if there is a, a difference in the way the database at traffic used to flow before now it's happening in a different way and so on. So that are products, which does that. Then we have the web application firewall or database application firewall, which sits around the databases, or there are controls that you can place in the database, which allows certain I users to do certain things, certain applications, to do certain things and so on.

And when we have the data centric security part, which is more to do with, how do you protect the data inside the database? So how do you, what do you do with certain aspects of data? Do you to credit card details, asset is the 16 of 15 digits, or do you do XXX on the first 14 or the 12 and so on? Or do you encrypt, do you redact? Do you tokenize and things like that? So that used to be the three big overlapping, but still a different part of the areas of database security.

What we are seeing here though, is that more and more people seems to understand and re require the need for what's called the two key factors of dynamic data masking and data access filtering. Now, the, the concept is very simple by dynamic data masking. What it means is that when somebody access data from the database, some of those data should not be given to the user user just plainly. So you either have to redact it. You have to transform it into something.

Or the data access filtering part is that some people just don't have the, the authority to access certain fields or certain roles in the data itself. So you have to completely remove it and filter it out completely. So that kind of sits in between all three different layers.

It can, and this ties in very cleanly with the, the generic requirement of moving APA, a wave, not into the database world as well. Now it would make it a bit more easy to understand it. Maybe with an example, from a regulatory requirement framework, how certain requirements lead one to move towards those kind of required it systems rocket and designs, which drive the solutions that we are looking into these days. Data flow across borders are increasing in the global economy.

Talk to any of the big financial institutions, talk to any of the, the big healthcare institutions that we have insurance companies and so on. You will see that they operate in multiple regulatory environments.

They, a bank headquartered out of the us would have a branch in Asia or a EU based bank. We'll have a American branch over there, and they have to kind of handle the requirements, free compliance requirements of all the different parts that they're working in when governments at the same time are also trying to harmonize, make it easier in a way for these multinational companies to work. And that they use that use the concept of multilateral agreements. So couple of acre examples, the EU data directive creates what's called the European digital single market.

So making it a bit more uniform in terms of how digitals transactions have handled within the European union, how legal compliance requirements can be unified across the region as well. And the APEC cross border privacy rules facilitate privacy, respecting data flow across the economies. That's part of the, the union. So you see a lot of these frameworks, which tries to make it easier. The last one last, but not the least is the O C D privacy framework.

Again, striving to strengthen the cross border corporation among privacy info authorities. This has come about bit just because of the fact that it's, we live in a network digital world, and people are not siloed anymore.

People do transactions all across the world and people still have to make it easier for institutions to operate across this, but that does not shield anybody from the basic fact that there are strict laws in place and harsh finalities in place to make sure that the data that's associated with the individuals are handled properly with respect you of what the financial incentives might be. The, the requirements from the companies might be, they still come under the regulatory framework.

That's Ash harsh, and as strict as usual, just to give you an example, the Singapore personal data protection act of 2012, made the monetary.

I thought of Singapore, this Montreal, Singapore made this act to make sure that the, the personal information about the user and the clients specifically, if you're looking at banks and financial institutions are protected to a very good extent, and they enforce this regulation by pro putting strict and large fines across companies who do not do do enough to protect, have things in place to make sure that these things are not out in the open and are strictly controlled.

So if you look at one example of an international financial institution, the PII relating to Singapore citizen process abroad must be encrypted in data at rest. And in transit, this comes almost bated from the, the acted itself. So if you have institution who has at caught say in somewhere in the European union of the us, and it's processing some of the data, and that's about a Singapore citizen, what it says that, that it should be interpret and in transit and in rest and decryption of that ly identify information is only allowed in the use cases where the purpose of use.

And now the purpose of use of course is kind of a bit of a fluffy term over there, but it has got some technical implications as well, motivates the display of this privacy sensitive data and the reporting tools that must be able to redact on mass values out of this sensitive data. So you see here that the data in the database that you are looking at is the core center centric thing that you are trying to protect, but the policy that's around it is not a very yes or no policy. There are policies that can be, that are very rich. That needs a lot of attributes. As Mr.

Kuppinger mentioned attributes about the, the client whose information is in the database attributes about the context in which the, the information is going, going to be used attributes about the user who needs to access that. And a lot of times we, the, the, the companies who handle this kind of requirements, find it challenging to Reen to implement these kind of requirements from a pure traditional access control, more modes that database security comes with. So let's look at a very concrete example of a rule.

If the personally identify information is about a Singapore citizen, then the user must also be a Singapore citizen user. In the sense of user of the, the tool who is looking into the data, say if you're using a BI tool or a reporting tool, the user who sees that personality information must also be a Singapore citizen. And of course that might be more other requirements as well, but this is one of the basic requirements that's out there. So you see that there is an, a relationship between the attribute that must be con met before certain aspects of the data can be revealed.

So if the user is authorized because the data was interest, you have to decrypt the data. While if the user is not authorized, you either leave the data interpret, or you mask it out into something else, depending upon how your application would process that data. So you see the requirements and the technical implication of how you would go about doing it, being very complicated based on the legal requirements, based on your local it policies and what the application actually wants to do.

Because if an application expects a 16 digit credit card information, if you put, if you don't put anything, there, there could be cases where the application just crashes. So you need to handle all these different kinds of requirements.

So from axiomatic side of things, when we talk to customers, and, and when we understand the requirements, the typical thing that we talk about in terms of the overview of the architecture is something like you have database applications or API gateways, all three kind of points where you can do some sort of authorization, all of them being controlled in real time by attribute based access control policy. So it's basically adapt to policy based access management APM brought into the concept of all the different tiers of database application API.

And specifically, if you look at databases, that's encrypted, you won't be able to show certain numbers, redact some numbers, encrypt some numbers, decryption numbers, or completely remove them as needed. So that's kind of the conceptual figurative way of representing the requirements that we see from financial institutional authorities. And from an architectural point of view, this is how the, a proposed solution would work.

And that's how our products work, which is where, when an application sends a sequel statement, that's in decepted at some point, and the query is sent to the authorization service saying in this case, user, Bob wants to select columns a and B from table T, is this allowed or not? Now the authorization service will have policies, which is written return using attributes as Mr. Cogan mentioned in the previous part of the webinar that will start evaluating. And it'll also call out to any other external sources.

For example, we may have information about the user who is trying to access the data in your, a directory, or for example, in another SQL directory somewhere, or maybe even the cloud, you can pull all those extra information that enriches your environment details. And then the authorization service evaluates and says, yes or no, that this cannot happen, or that can happen, or yes, but you need to do certain extra things before that information is sent over to the user.

So in this case, for example, what the result of the sequel statement is, is basically saying, yeah, you can do it, but that has to be a transformation. In this case, you can select a, but you have to mask the value of B and that's what is finally sent and hit the database and the database. And so with the filter data in a, a way back to the application.

So what you see in this architecture here is that you're able to control what the database is able to put out using a centralized authorization service that uses policies, which are external to their database itself, which are managed centrally, which can be, and which using attributes from all the different parts of the system, the application environment, details, the user environment details, or even it could be breaking the glass ceiling kind of policy, which would say that, oh, disregard all the other hundred policies because a national emergency has been declared in this part of the country, or there is a big earthquake, or all those kind of exceptional circumstances can also be codified into your policies.

And that together allows you to write very good, very policy centric rules, man, makes it easier for you to do regulatory compliance. So some simple examples let's assume that you have a database which consists of a table, say employees holding employee datas, let's say the name, the salary, and the department B C D in this case, actually, there's no C even it's B and D.

And what the axiomatic data access filter would do is monitor this database and enforce the policy that you write against what kind of policies let's take a look in this case, we are doing access filtering for a user, Joe, who is a department manager. That's a role he has, and that he belongs to the department D then what he's trying to do, either using some form of a, a console or within an application or an application acting on behalf of Joe says select name and salary department from employees.

And that's the, the sequel query that actually gets sent over from the application to the database and the business rule. However, says that a business department manager can see the records of a subordinate only if it's within the same department. So if you are from D and you are a department manager, you should only be able to see the information about your subordinates, who are in department D alone.

So in the previous example, you could actually see that there were a lot of columns, which was a and B, but if you enforce this business rule, this is what you should be doing, which is data, access, filtering those things, which do those roads, which do not meet that requirement should be filtered out. And what should be sent out is in this case, just two rows for employees who belong to department D because that's what Joe is manager of. So you can see that the rest of the data, even though it's in the database, never gets out of the database.

It's not that the database sends over everything to the application, the application filters it, and the application sends a partial list to the user, nor is it the fact that the application does the logic of, oh, okay. I need to change this statement to something more restrictive and sensitive to database. That's not even the case. The application still asks for selects everything. And the database still gets only the partial list that it needs to send it's in the internal middle of it, where the magic happens.

Now, another use case is exactly the same thing. Joe department manager of department, D trying to do the same things, name salary department from the table called employee. But the business rule is slightly different here. There's one more, I guess, a loser constraint, which says here, they can see all the employee details, but not the salaries, the salaries of only the staff of their own department. So you can see the name.

You can see the department, but you cannot see the salary unless you belong to the same department as the use, or as the client, the customer that you're talking about in this case, the employee. So here you don't filter out information completely from a row because the row itself can be shown. It's just that some columns or cells within that columns have to be masked or nullified in this specific case, because you'd have to show nothing.

And the result of that would be something like this, where you can see everyone's information in terms of name everyone's information in terms of data department. But the salary itself is must. If you don't belong to the same department as they use as the, the employee, while if you belong to the same employee department in this case, D you get to see the salary as well. So you see the more richer policies and how they are enforced.

And the, the salaries stem self of others are masked out, and you can do multiple combinations of functions. You could have decrypted it, encrypted it at it, or you could have, you could have tokenized it, a lot of different options are available to you. That depends upon exactly what the policy says.

So from an architectural details point, if you, if you are interested to see exactly how this happens, technically is a bit more complex, but let me take it one by one, you're looking at basically an application who sits over there, who talks and is ed to talk to the database, but through what's called the SQL proxy. So there's no way for the applications to talk directly to the database. It has to go through the proxy. And that proxy is basically what Mr. Kuppinger mentioned, as the policy enforcement point. That's internal here. What this does is the application intercepts.

The call to the database, sends the query over to the filter service, the filter service, which is the ball, basically the equivalent of the policy decision point, where it evaluates the policies, finds out more attributes it's needed, and it can be configured using the exact new policies that we rely on for writing your, a back centric policies. And this then rewrites this equal query that was sent over to it based on the constraints that's available. And that exactly is the one that's pushed over to the other side, back to the database.

And the database then sends out the filter data back to the application. So that's the overall high level view of how you would see the different components working together in the product and the architecture details of how a database centric, a data centric aback system would work. I think that's, that's the end of my side of the talk webinar. Mr. Kuppinger happy to take questions, I guess if that's it, but I'll have to over back to you. Okay. Thank you. I will just quickly switch to moderator role presenter role again. So here we go.

Again, we have already some questions here, and as I've said before, please enter your questions so that we can look at them and answer them, or try to answer them. Thank you. Throughhi for your presentation, which was very interesting. So let's start with one question, which is, I think not surprising, but definitely important. How's the application performance from a user perspective, with all the policy of affiliation in place. So this is the question, or maybe, maybe you look at two scenarios, one is compare, or you might compare it to doing nothing and two doing it with coded security.

Yeah. So if you do nothing and if there's no, absolutely no access control, of course, there's very little overhead, but that's, that's not allowed and reasonably when to assume in this day and age. So if you have application coded security, you could have applications writing the, the logic of the access control in there.

The couple of problems with this one that you mentioned is the fact that you have to handle all the change process and everything, every time a policy changes, but from a performance point of view, that will by itself have overhead compared to the first where there is no access control at all. But more importantly, you will see that the applications that have this asset control, I have very limited set of policies that it can enforce there.

And if, if you explore that number of policies, that's possible, you do see an overhead there as well. Now, if you come to the, the solution that we are mentioning here in this webinar, we, you will see that you have different options on how do you actually implement it. You could implement it as a service, then you will have some latency issues.

But what we have seen in the real world is that if you have very high volume transactions, when it comes to selects, there is about five to 10% overhead that you would see the evaluation of the policy itself is very little part of that overhead because our engines have been tuned to do the evaluation very, very fast. It's mostly related to latency related to end the network.

And if you have, for example, attributes in your SAP system, which is in the cloud somewhere or Salesforce system in the cloud somewhere, and if you have to call that out and get that attributes, it's gonna cost a bit of a delay. But if you minimize that and manage it, the overhead is not that much. Okay. Not that much means The worst we have seen in a nicely regulated environment is about 10% max. So five to 10% is what we have seen. Okay. Another question on slide L 11, you you've been talking about a user show.

So how is the usage show authenticated to the database or database access filter in that scenario? That's a, that's actually a very, very nice question. And that's something that we, we, we actually see and that's, I guess, pertains to your slide as well there, because we do have that. We do see a lot of application, which has that disconnect because as you said, people authenticate. And for some reason that authentication session does not go translate all the way to the application. Maybe not the app server and definitely most of the time, not to the database server.

So there is a need for a innovative retrofitting in the application of the way it's done. But there are a lot of cases where you can tunnel in the user information. Doesn't have to be all the things that's available in this session, but basic key attributes in this case, for example, user ID, session ID, and things like that as a part of the SQL query, that's coming onto the database, or it can be written as part of the Java environments that's going on happening.

The, the, the sequel proxy that we use, it's a O component. They are very good capabilities to sniffing that out. So if you are, for example, using an application on your windows, desktop machine, and to connect to an application which connects your console or database, it can use the, the locking in information of your windows machine, for example.

So there are different ways in which you can glean that out, even if the application is not sharing it openly, but in some cases, a lot of times, I guess we do need to retrofit some basic information about the user and pass it along to the database. Okay, perfect. Another question comes in. How does it hand adding the filters onto store procedure calls instead of straight sequel work, where clause queries so SQL, where, so Steve look wear sort of typical look type of queries. So how does it handle it in case of certain procedures?

We, we, we do have support for storage procedures as well, and we'll be more, I'll be more than happy to talk about that in detail, maybe, maybe over email, I guess, but it it's, it's possible to do that. It, it depends upon how you intercept and how you rewrite the queries as well.

And I I'm, I'm guessing it'll be more interesting to look at a specific use case as well and see how it fits. But we, we do have support for hairdressing store procedures as well in our product. Okay.

Maybe one, one other question, which is the right part, the role of standards and that. So we see X ACML on one hand, we see open set. So what is your view and the standards and the role they're playing and, and, or will play in the future. So what is your point on that? Right.

So, as we mentioned, a couple of times in the webinar, we, we primarily rely on open, sorry, a, the extensible access control market language, it's in version three right now. And it's, it's actually pretty mature standard from, from the looks of what the customer thinks and the vendors that who have been implementing it, but we do need the ecosystem to build around it. So the exact mold as a standard have been adapted by a lot of vendors and a lot of customers and open a Z is actually in a way an extension of that ecosystem because it, it, by itself doesn't create their own standards.

It uses open exact mold inside. Most of the frameworks, what is trying to do is make interoperability between vendors a bit more easier.

So this, the standard itself says, if you wanna ask a question, ask it in this specific format, if you wanna write a policy, write it in this specific schema or semantic, but it doesn't go down into the technical implementation detail saying, oh, this is exactly how you use a method to ask that question. And that's where open a Z is trying to do, which says, okay, look, if you write, if you talk to a vendor, a and you decide on using that vendor and you write a lot of your applications using that. Now you suddenly move to vendor, be you have right.

Written a lot of things based on the SDKs of that vendor. And now you wanna move away. So you need one level of abstraction, I guess that makes it easier for you to interoperate. And that's where open a Z one component of open a comes into play as well. The other aspects is when it says, okay, you talk to the pep, talking to the PDP, you use this language, but then what exactly is the web service call? That's up to the vendor.

And that's again, where open said tries to make a moderation role and say, okay, let's put a nice kind of interoperability layer, making it easier for everybody to talk to everybody else. Okay, Perfect. We do need these standards. Definitely. Yes. One other question. Do application queries need to be modified to make use of data, access filtering, or dynamic data mask. So the applications queries don't have to change at all.

It can do exactly what it was doing before, and that that's actually the strength of the solution and the approach, which is that the application keeps asking for what it was asking before the rewrite happens transparent to the application and the application gets back, what's allowed as per the policy. Okay, perfect. So I think we've gone through all the questions. Thank you for, to all the attenders for attending this. Copy our call webinar and participating also so actively in the Q and a session. Indeed.

Thank you to you sheet for your presentation and all the information you delivered, hope to have you back the attend and all the others in one of our upcoming webinars or other copy a call events. Talk to you soon again. Thank you. Thank you. Copy again. Thank you. Bye.