Extending Data Governance Beyond the Database

Good afternoon, ladies and gentlemen, welcome to our KuppingerCole webinar. Extending data government beyond the database. This webinar is supported by Oracle. The speakers today are me Martin Kuppinger I'm, founder and principle Analyst at KuppingerCole. And on the other side, it's Roxanne bures director of product management and strategy for database security at Oracle. Before we start some general information, some housekeeping information, I will keep this short.

So let's start with what is keeping a call, keeping a coal list, some Analyst company we're providing enterprise it research device, decision support, and networking for it. Professionals through our research service twice services and our events. You'll find more information about it on our website, our main event, European identity and cloud conference, which by the way, also has a big data security track looking at security Foric data security by using the data governance aspects, etcetera privacy aspects for big data. This conference will be held May 14th, 17th in Munich.

You shouldn't miss this event. It's primary. And when within Europe on the some guidelines for the webinar, you are muted centrally. So you don't have to mute or UN mute yourself. We control these features. We will record the webinar and the podcast recording will be available tomorrow.

By the way, also the slide X of both Roanne me will be available as PDF versions latest on by tomorrow for download question and answer will be at the end of the webinar, but you can ask questions anytime using the questions tool in the go to webinar control panel, the go to webinar control panel, something you'll find out the right side of your screen. And there's an area questions where you can submit to your questions. We will answer the questions at the end or if appropriate during the webinar. So let's have a look at the agenda.

The agenda for today, let's split into three parts, like most of our clinical webinars. In the first part, I will talk about how database security fits into the approach of database governance and information. Steward chips are really starting with the higher level picture, which technologies are relevant, Darin and what it needs for a holistic approach or database security security beyond the database itself.

And the second part then Roxanne ESCO will talk about details about extending the approach of database governance to data governance beyond the database, by combining and extending database security functionality. So sort of complete security for databases across all the stack. And like I've said, the third part that will be the Q and a session. So let's directly start with the, the presentation. I start at a very high levels.

So two colleagues of mine, Dave currents, and Mike Small originally did report, which was called from data leakage prevention to information stewardship sort of setting a, the bigger scene of this entire thing around information security, etcetera, and information stewardship in fact is sort of the, the real big picture where it's about managing the information lifecycle, understanding the business value of information by rating information, etcetera, having the data architecture and knowing where which type of information should be held and will be held, looking at information quality, looking at the aspects of privacy and compliance, and finally also security.

So information security is some information. Security is a piece of a, a bigger thing, which is really information stewardship, handling information appropriate way. And within this security is important. And for sure, database security as sort of the dealing with the mass of structured data is a key element. And on the other hand, database security not is not, not something which is isolated from the rest.

So, so all the principles of good information management and good information stewardship for sure also apply to databases and database security. And that means also that the typical sources of risk, which we have here. So these typical sources like malicious activities, misuse mistake also apply to database and database security. We have malicious activities like coordinated ad hacks in the case of database, for example, SQL intraction types of ad hacks, hacking data theft, denial of access, like mailing. We have the app, the app use of privilege that also is around data theft frequently.

So if you look at the tax issues and Swiss banks, one FDA area, so typically of app use of privilege, the tax data theft, which has been sold to German government, sometimes it's just curiosity cetera. So a lot of things are misused, not in a, in the, in the meaning of it's really a malicious activity, but it's something just done wrong. And then there are the mistakes or accidental loss. Ential erasure accidental disclosure.

And we, we, we need to understand what is happening here. We need to mitigate these risks by taking appropriate access by implementing appropriate technology at all levels, especially because data is used in various situations. So if you look at data and databases, the attacker might work at the level of the server of the underlying server by trust copying the entire database. He might attack the database, but there might be also data leakage, etcetera, at the applications using the data out of these databases. So there are really are various levels.

And we have to, to, to understand which are the, the potential risks, what could happen there and how to mitigate this Within the concept of information stewardship, we have three areas which are security, which are processes and which are sort of the elements in the sense of technical solutions, which we can use to mitigate risks there.

So what we have to do is we have to ensure confidential, to integrity and availability of data for all types of data, including database that requires some specific types of processes, like information classification, access policies, and controls, business continuity, planning, and auditing. So these are things we are, we are looking at in this area. We have different types of process. And then we have a lot of elements which help us to mitigate with flag identity, access management, privilege management, secure storage, flow control.

So where data flowing, infrastructure, security, information, loss, resilience, mitigation, and monitoring, and review. And then when we take a look at the database layer, a lot of these elements are relevant for databases. So database governance, that's around privilege management. So it's really about how do different type, how do we deal with privileges? The DBA privileges, etcetera, secure storage. That's also part of database governance specifically for database, not only for databases. So there is a secure storage issue. Also beyond the database, we have to flow control.

So protecting data at move, we have to infrastructure security, how to secure the entire infrastructure, the underlying network, how to, to, to start protecting access at the network layer by using database firewalls, etcetera, we have to monitoring and review part, which is also around reviewing all these things for traffic happened. Also the forensic part, the detective controls cetera database governance there in is one of the elements. So within information stewardship, we have a lot of dis and we have to understand where is the biggest risk.

And one of the areas where we always have a big risk is DRF databases because in the databases we are old, like I've said before the mass structured data. And so we need database governance. We need to have the entire set of policies, procedures, practice, organizational structures, to ensure the execution of database related activities, according to defined strategies and control. So that's what database governance is about. It's one part of the bigger picture. It's something we, we need to do within the context of information stewardship, and we need to do it right.

So I started the level of information stewardship. I look now at the level of database governance, then I will go first down what you do specifically and how to extend it to the entire stack. We are looking at when we are looking at QRC database governance, that's part of the governance risk compliance areas. Then on the other hand, we are observing something which I tend to call separate worlds. So we have a lot of layers of QRC. So we have the it QRC.

We have it risk management, enterprise QRC, business chair, CEO, operational risk management, access governance, database governance, etcetera, etcetera, just put in some of the, the most prominent layers in there. The problem was, this is in fact that is sort of a, a world. So we are looking at, at a lot of these things, very isolated and people which are looking at business JRC, do not tend to talk much with the people which are, who are doing it JRC. So we have an issue there.

However, we, we need to understand that these things are related and we have to move forward by really integrating them better. I think that's the same story. Like when we look at big picture of information, governance and database governance is one part of it. And it's one part of the bigger QRC picture. When we then try to put database governance into context, We have, and it's a little bit different view.

The QRC, we have the field of corporate governance, which is around really the high level book of rules, the general policies, strategic risks. We have the area of business literacy, which is about operational risks, continuous controls, process, and risk controls. We have the level of it literacy, and that's really where we look at it, risks and the different types of it, specific governance, including access governance, cm, et cetera, but cm, in fact, more than the technology below and looking at database governance.

So one, this sibling was in it. CRC really is the discipline database governance, and we need to technology to really do that. And that's where really all these common technologies come into play. It's access. Governance is provisioning. When we look at and their access across heterogeneous infrastructure in it, we have cm, we have service management and we have database security there. So what we have in fact is at the high level, we have corporate governance, which sets the big scene, which in fact also includes that we have to have information stewardship in place.

We have the business JRC level looking really at the business processes. We have the it part, which then really looks at duties. It systems work well with different disciplines of governance, including database governance. And then we have the technology to make this work. And so that's really the point where it comes, where we have to look at. And clearly when we look at the bigger picture of QRC, we have to look at also at the integration of various it QRC parts of various supporting technology.

So we have to look beyond the pure data side because we like we can see in that picture, these are a lot of different disciplines, which are related to each other. And when we go down the path, we should be considered doing it the right way. So currently, so one of the issues we have is that we do a lot of different GRCs. The other problem we have is that we frequently do it more tactical, not strategic. So we do it in a way, which then from a cost perspective and from a time perspective, looks a little bit that way.

So the cost is we have sort of in trouble, we say, so we have trumps of cost. We have blocks of cost. What happens?

In fact, we have audit findings and hopefully at some point we have no or few audit audit findings, but if you do a tactical, probably we will remain with always new audit findings. And once the audit finding was there, we switch into panic mode, we invest a lot. We spend a lot of money and then we lose focus and things get worse again. And then the next problem occurs. Panic mode, investment. We have relaxing again, audit finding panic mode, et cetera, doing a strategic is the better way.

So really investing a good well-defined infrastructure, where we have a good understanding of what do we need for information stewardship? What do we need for the really the enterprise QRC and the sense of putting all the QRC parts together? What does it mean for database governance? What does it mean for database security? What does it mean for other areas? And then investing focused in building an infrastructure helps us to really get better. It's sort of, instead of working to the audit, it's about working to the business. And so that's basically the idea.

When we look at database governance, there are some clear objectives. They are basically the same, like for the information stewardship itself, it's availability, it's integrity, traceability, it's authenticity, it's confidentiality, it's privacy. So we have to, to, to enforce these things within our database governance things, and we need some, some technologies to do that. And when we look at the bigger picture of database governance, then there are a lot of different technologies amongst these tech technologies.

There are the technical features within the database itself, like locking authentication access management. There are database security tools like database firewalls, like data masking tools, and other works probably will also talk a lot about this. There are other tools like privilege management tools. So P XM privilege, account user, whatever management user channel purpose for DBMS or specific to specific tools for databases. So how to manage their privilege like DBAs, etcetera provisioning, user, and access control to the database, the higher level QRC.

So providing the database governance information into a higher level view dashboard for CEO, CEO, cetera, access governance for review and access and access controls. And for sure, the integration with C and enterprise lock management, as well as with the specific lock management capabilities for databases. When we do that, we have to find a mix between two things which are preventive controls and detective controls.

So we, what we need to understand when really implementing database governance, right? First of all, is it's not one technology, there's an area of preventive control. How can we prevent that? Something goes wrong by defining correct access controls by using database firewalls, to analyze the traffic and to block attacks, et cetera, by encryption. So that data is just secure when it flows across the network or when it's sitting in the database and the storage. And on the other hand, we have detective controls like especially log analyzes.

So looking at what has happened, where there are any types of attacks. And when we right now say, okay, we, we look at this picture of information, stewardship, we want to protect information. Then we clearly end up with, we need to protect databases. So we are at the level of database governance within database governance. We have a lot, lot of technologies and we have to understand which ones do we need for preventive controls and which ones do we need for detective controls? So what are the most important technologies?

And that leads to a, a situation where we will easily identify, okay, there are different types of technologies. And I've put this into a pretty simple picture, which we can extend by a lot of technologies. But I think this picture helps to understand sort of the, the basic problem there, the problem, I would say, it's press versus death.

So we can, we have solutions which are support broad set of technologies, like general purpose firewalls. So standard firewall can filter oral type of packets, but it doesn't know virtually anything about database specific traffic. Maybe it knows a little bit about it, but that's it on the other hand with focus only on the database firewall. So not breadth, breath, but narrowness sort of things. And on the other hand, that's so really going to the detail. Then we are at the database firewall level. And on the other hand, we could do the same with cm.

So cm are tools which support a broad variety of systems, but they don't provide the level of detail. On the other hand, lock analyzes is going into detail.

So, and the interesting point is there's literally nothing in the lower right edge. There's literally nothing in the, maybe there's something in the upper left edge, but something which it's a person only databases at a, let's say at a very low level with not much that doesn't make much sense. So the upper left edge doesn't have us really, and the lower right water end. The problem with this would be that these tools would be too complex. Clearly we need both.

And what we need is the right combination of things we need to understand where do general purpose tools help, and where do we need more specific things. And when we look at the area of preventativeness, we have in the area of preventativeness, for example, the network firewall that's first layer of security, the database firewall, the database access controls, database encryption. So we have various levels and we should always work with various layers of control.

When it comes to detective seal with more than Martin purposing, a database log is more specific where we have a database log specific analytical and forensic capabilities. We are very specialized. It's a very deep approach, but it's not a broad approach. It's not about supporting everything. On the other hand, it's clear that when we look at an attack surface and attack vector, it's not that this is only to the data we targeted to the database.

So at the network firewall level, we might identify, okay, there are attacks which affect the operating system and the database with a purely database firewall. We would only see the database specific part. So the best approach is to really, to filter a lot of things at the first line of defense, having additional lines of defenses and what is really worse to consider.

And that's where we move from database security to security is even when we look at specific layers of control, like database firewalls, or database log analytics and forensics, to which should we expand them to support the entire stack of a system where the database sits on the stack from the network to the hardware operating system, database applications. So what should we do there? What I want to say is database security is part of a bigger story. We need to understand.

It's, it's a bigger picture we are looking at and we need a layered security. We need multiple layers of controls. And the thing that we really need to think about is where can we just focus on the database and where does it make sense to expand it? What clearly doesn't work is having one tool that for, for everything. So there's not the tool which solves all your security problems in once for preventive or for detective.

But there's, I think a fine balance between the very, very specific tools only for the database and expanding them a little to support the, sort of the entire stack around the database. And that's where Roxanne will tell you a lot of, I think, very interesting things around. So I will hand out right now to Roxanne AER. Okay. And I'm so Roxanne, it's your turn. Thank you, Martin.

Oh, good. Can I, can, can you see my slides? Okay. Yes. Perfect. Perfect. So I'm just gonna pick up a little bit where Martin left off and discuss one of our new solutions, Oracle audit, vault and database firewall, and how it fits into the data governance and the technologies that that Martin discussed just now. So very much, very similarly. We think about database security in terms of preventive detective and administrative controls.

And the main reason that we think about, you know, obviously we think about all of security, you know, as a, as a, as an industry, we think about security this way and governance this way.

But the key thing in database security is that if you look at the industry reports, the attack vectors and the attack surface, isn't really the database itself attacks to the database really happen through legitimate access to the database, right through compromised credentials, stolen through malware, where, you know, an attacker will essentially access the database as a privileged user or through SQL injection attacks by which an applica by which an attacker takes over an application. And again, uses that legitimate access that the application has to the database.

So when we look at database attacks, right, really we're talking about legitimate access and the need for controls around legitimate access, which then translates really into a governance, right. Essentially who should have access, right? How do I put in place those controls in order to achieve my security objectives and even controls? We think about them, obviously in terms of preventive, detective and administrative type of controls, we've always had preventive controls built into the Oracle database, right?

So these preventive controls are gonna be integrated into the Oracle database, really because you need those as close to the data. Essentially, these are gonna be the access control kinds of things that, that Martin mentioned earlier. And we want those built into the database. You don't want those essentially bolded on, they should be transparent. So for example, transparent data encryption for data at rest, things like redaction and masking for being able to return back data in an unencrypted way, in a usable fashion to applications and to users.

And of course, user controls in terms of, again, what happens when you have those compromised credentials. Now these preventive controls within the database are, are great, but we also wanna establish detective controls outside the database and really provide a first line of defense that baseline that'll provide activity monitoring, but once we're outside the database and we're looking at activity, of course, we wanna be able to prevent those unauthorized activities as well. So it's kind of a little bit of a misnomer.

We put database firewall as a detective control because really it relies on detecting unauthorized activity. But of course, if we're gonna detect an authorized activity, we might as well stop that. Right. And then of course the auditing and reporting that we need for those compliance for regulatory audits, so that we're not always in that panic mode. And once we have these detective controls outside the database, essentially what it allows us to do is in some sense, extend the controls that we already have within the database, providing another layer of security.

That's really part of a defense in depth approach to database security. So I just wanted to put that in, in, in sort of in context, really to, to, to, to, to drill in on the detective control piece that we're gonna talk about today. So the activity monitoring database activity, monitoring the database firewall and the auditing and reporting, and what we've done in Oracle is provide a complete solution that addresses all of these different, all of these different types of controls in one single solution for, for database and data infrastructure.

And that solution is called Oracle audit vault and database firewall. And essentially there's two components. So similarly to let's say doing the networking world to, you know, IDs IPS, we wanna have a database firewall that monitors database, that monitors database traffic.

Now, when we're talking about database traffic, we're not talking about the network traffic, right? That would be the traffic that your network firewall is monitoring, but really the database traffic, which would be sequel statements coming from users, things like DML data, market language DDL, right? All of the various languages of the database, right. That's database traffic. And we wanna be able to monitor that traffic, whether it's coming from users, from applications, all of various sources sitting essentially in front of our databases.

And we wanna apply policies to that traffic to determine whether we should allow it through whether we should block it or potentially substitute it. Right. So essentially providing that, that IDs, I PS type layer for our database.

Now, in addition to that, we're not gonna be able to see everything that happens within the database strictly on the wire, right? There's things that happen within database, like stored procedures, things like operational scripts that are run on the database servers themselves. And additionally, from an, from a regulatory standpoint, we also really need to audit trail from the database itself for things like e-discovery and forensics. So we wanna also collect all of that audit data and have that into the same repository that our firewall data is coming into. Right.

Cause in some sense, that's providing a level of activity monitoring as well. So it's the audit data. And on top of that, we also really wanna look at the entire database environment. So we wanna look at the logs that are coming in from the operating system. So for example, who's doing things like SU from the directory servers, from the file systems.

Most, most of us these days are using journaling file systems. Those have an audit trail as well, right? As well as custom audit log. So logs that our applications are generating either in a flat file or in a database table. And we wanna have all of that in a SU in a secure, centralized repository for the entire enterprise, and then be able to generate the reports, the alert, the policies, of course, right.

As to who should have access to what, and of course the, the general analysis that can come out of looking at this kind of data and actually it's really a, a cycle, if you will, where you're thinking about, you know, okay, based on this while this should have never happened, I need to change my policies. Right. So essentially having that complete, having that complete infrastructure for data governance, that's really outside of the database and one single solution.

So I'm gonna drill down in a couple of these functions just a little bit, and I wanna make sure that we have time for any questions in case anybody would like to understand this better. So as far as, as far as, how does, how does that white list work? Right. I mentioned earlier that this is very similar to, to, to an IDs I PS concept. So how do we think about that?

Well, if you think about SQL that's coming from a normal application, right? So your application might be doing, let's say, you know, a catalog, right? So we're looking at, we're gonna provide a list to somebody of all of the items, a specific item in our catalog. And there would be a select statement that picks out something for a particular catalog number that's normal, what the, what the normal SQL statement would be look like.

Now, if somebody enters a SQL injection attack and a SQL injection attack, if you're not familiar with it, is when somebody uses, let's say a field on a, on a web form, for example, instead of actually input in a legitimate value to input a SQL, to input some SQL statement, which would then be merged by the application with the sequel that would normally send to the database and essentially construct a completely different operation that the database will then execute and return back through the application to the user.

So here's an example where somebody tries to jump out if you will, of that catalog, you know, from that stock table of items that we have, but essentially inputting a sequel statement instead of a legitimate catalog number. Now you can see the difference between the two statements. So one would that hits our firewall. Clearly that's not gonna be on the white list, right. And that would is then essentially be, you know, be, be rejected or potentially substituted, right? Because it doesn't match. It's very easy to set up these white lists for any kind of application.

Most organizations have things like regression test suites. So you can even do this as part of your development process, right. And anything that's out of policy immediately gets blocked or alerted. And one of the, the, the key aspects to this is really that this white list approach is really the most powerful approach when we're looking at things like governance and security for that matter, because really the, the, what we know is what's, what's allowed, right? We know what's good.

The, the universe of what's not allowed is incomplete. If you will, right. It's ever expanding and incomplete, you know, there's always gonna be new attack vectors. There's always gonna be different things that people will try. On the other hand, we know very well what's legitimate action, right? So the white list is really the most powerful approach in terms of enforcing, you know, data access policies that said, we also offer negative security policies, essentially a blacklist model, because that has its value as well. You don't wanna rely exclusively on a blacklist, right?

This would be the equivalent of, you know, virus where in PC land, for example, where you have a blacklist with signatures and your attack signatures have to be updated every day. Because again, it's a very incomplete kind of solution. If my virus update isn't, you know, if my virus signature isn't up to date, well, a virus can get through, right? So that doesn't really work right for, for a data base and a data center type of environment. You can't have things auto updating.

However, the black list is very useful for identifying certain kinds of activities that we may not be able to always to be, to always know. So for, for example, DBA activity. So DBA activity isn't necessarily gonna be something that could be on our white list, cuz it's gonna be very variable. Right. But what we can do is take into account different factors in all of our policies, whitelist and blacklist policies and say things like, well, if a database administrator is accessing the database from an application that looks softly suspicious, right?

I mean they should be accessing the database from their workstation. So those are the kinds of things where let's say, if it's coming from, you know, from an application server, we may wanna block that. Right. So anything that, you know, any database activity coming from an application server automatically gets it's on our blacklist. It automatically gets blocked or alternatively, we may wanna increase the logging level. Right? So again that we have more, you know, more proof and more information as far as, as far as regulatory audit goes, right?

A lot of times we're using auditing as compensating controls, right? For certain kinds of privileged user activities, right? So we wanna be able to have that additional, that additional level of logging that shows exactly what, you know, what our privileged users were doing. So there's a huge amount of flexibility between this kind of approach with a whitelist and the blacklist to really be able to enforce pretty much any kind of policy really before you've even hit the database itself. And this is very powerful, right?

I mean, I can, it can essentially enforce data and database infrastructure policies before even hitting the database itself. Now, the audit I mentioned, you saw earlier on the diagram that all of this information is, is, is consolidated in, in a repository, in an audit and event repository. And then on an event, repository is based on an Oracle database and do a few things within that, right? I mean this, depending on your data retention policies, you can have a fairly large and the size of your organization.

You can have a fairly large repository that you need to maintain for many years, right? I mean, data retention policies are easily three years for many organizations. A lot of times they're even longer. And you want that, right. Especially for forensics. Unfortunately again, going back to a lot of industry reports out there, it takes months. A lot of times, even years before breaches and certain kinds of, you know, of information theft are discovered. So you wanna have that data be available online, be easy to analyze.

So one of the things that we do is not only take advantage of compression that's within the database and partitioning, but we do things like information, life, cycle management for the specific target. And what that means is that we can keep the most recent information on, you know, highly active partitions and essentially automatically age that out to different partitions. What that means is that you can still do all of the reports that you needed to do, and all of the data is still available online.

So if you needed to go back to see exactly who accessed what three years ago, that would still be something that you can, you can go back and do very easily. You don't have to, you know, start to look through audit trail, you know, logs and bring back logs from, you know, from storage facilities and things like that. And of course, all of this is highly available and it's an open scheme up.

So there's a number of reports we're gonna look at in a minute, but there's also an open scheme up so that you can do any kind of reports that you want to, there's also information, life cycle by target, right? So essentially if I have certain databases, for example, that might have financial information that require a longer retention policy, for example, than other databases, a centralized web console for EC administration. And of course, you know, various command line utilities as well for automation and scripting so that you don't have to do everything through a gooey.

I'm just gonna give a couple of quick examples of what some of the, you know, some of the screens look like just to give you a flavor for the solution. This is the example of the single administrative con console. You can see here that I can manage all of the target. I can group my target. I can have different kind of entitlement snapshots, so I can see exactly who's got access to what, and again, here's where I can set up the different enforcement points. So these would be my firewall instances and I can see all of them.

I have one let's say in front of my, I have a firewall in front of my CRM database, a firewall in front of my, of my sales database. And these would be my, my targets that I'm managing through the console from a report standpoint, there's a number of default reports available. So things like activity overview, who's modified data. Who's looking at data.

Another, another interesting fact, we, Oracle sponsors user group survey every year on data security practices. And every year, you know, for the past couple of years, we've seen people respond that only 30% know are monitoring. Who's looking at sensitive data. So in other words, unless you're looking, unless you have a solution like, like firewall in place to monitor or audit event in the, in the database to see who's actually looking at data, most organizations, 70% or so of them don't even know who's accessing that data, right? So who's looking at that data.

So you have all of those reports obviously failed logins, all of the things that you need for different kinds of compliance reporting, which brings us to compliance reporting. We find that for compliance report reporting, and this is sort of an interesting point related to, to the chart that Martin had put up earlier about tactical versus strategic.

Well, it's interesting that most compliance regulations, when you really drill right down to it actually require much of the same information. So if organizations take a strategic approach to, to regulatory compliance, rather than a reactionary or tactical approach to regulatory compliance, it turns out that many of these regulations actually require the same type of reports.

So what we try to do is actually provide the core reports that are needed and then allow you to associate those with all of the different, all of the different re regulations that your particular organization might be, you know, might be subject to. I mean, typically most organizations, aren't just one regulatory requirement, right? You might have PCI. This is obviously for, for us organizations, you would have HIPAA, you would have Sarbanes Oxley. So many of many organizations have at least these five, right? Typically many more than that as well.

But when you get right down to it, the reports are actually the same. All these regulations wanna know who has access to what, what data has been modified.

You know, things like that. This is an example of what it would look like when we actually block the sequel injection attack. I showed earlier. If you recall on that white list that, you know, any statement that would look that would contain a sequel injection attack would be stopped. And this is an example of a sequel injection attack that was detective and would be stopped.

Now, most of you, if you have applications that are sitting on the internet are getting literally hundreds, thousands, minimum of SQL injection attacks on a daily basis. If you have a firewall solution like this, you can actually start to see them, right.

I mean, you literally start to see these going, you know, to your database and you can stop them and notice we've blocked, we've masked out the social security number. So that's another feature as well, because you don't wanna create yet another repository with sensitive information. I mentioned earlier, the value of auditing, right? And I wanted to stress that again, because you can't really do everything through monitoring on the wire. Right? So if you're really trying to get a complete view of all of the activity within your database, you can't do that strictly through monitoring.

We need to be able to also look at things like auditing, using native auditing, to look at things like storage procedure calls, for example, which aren't gonna be visible on the wire, right? They're not gonna be visible at any point, except within the database itself. Right? We've got things like reversive SQL. So SQL statements that essentially generate other SQL statements. So this is an example of where, you know, through, by capturing the native audit trail, we're seeing these stored procedure calls that we would, that we would not have seen any other way.

Now we can of course, report on the data from multiple sources. So now we can take, not only the, the, for example, the network monitoring example that we saw earlier in the system and the audit trail, but we can also start to get things like, you know, events from windows, right? So from our event log, so here we see log on events that are coming in from the operating system, right? Because we can capture that operating system log as well. We can capture directories logs as well, too. Right?

So all of that can get captured into a single repository and we can report across all of the different sources of information, an audit detail. This is just a quick example.

I mean, obviously they're, they're very detailed. It's it's we have a huge rich amount of data that all of these, that all of these sources produce today, right? The windows directory produces a lot of information in its audit trail windows, log events, produce information. This is an example of an Oracle database audit event where you've gotta essentially have the complete sequel statement. You have the variables, you have a lot of information about the, about the state of the database when it was actually executing that that's very valuable in terms of forensics information as well.

And of course, alerting, right. I mentioned earlier, obviously, when anything happens, we wanna be able to get alerting.

Now, one of the things that we want with alerting is not a lot of false positives, right? So we wanna be able to really focus and be very fine grained in terms of how, you know, in terms of these alerts, right? So being able to group them threshold them. So for example, I may not care about a single failed login, but maybe I care about 10 sales logins in a five second interval. Right?

So, and, and of course, more sophisticated kind of events, a really good one is around people selecting data, right? A lot of times people wanna know, well, you know, is there, is there a way I can get an alert for, you know, a million, somebody who selects a million credit card records?

Well, the reality is that most people aren't gonna, you know, an attacker isn't gonna select, you know, million credit card records at a time because they're smart, right. They know that that's gonna trigger some sort of alert, right? So what they're gonna do is they're gonna issue the same statement, right? 10 times a hundred times, right. But it'll only pull a hundred, let's say, or a thousand records at a time. They're not gonna do a million records at a time. They're gonna do a hundred records at a time.

So what you wanna do is be able to see those types of statements and then alert if, for example, a user is executing a particular statement with, with a certain level of frequency. Next thing I men I wanna mention a little bit about is deployment architecture.

So again, similar to similar to IDs, I PS we have a similar kind of analogy in terms of how we deploy database firewalls. So we can deploy in an inline mode essentially for looking at, for, for stopping traffic. Essentially, this is a layer two solution. I'll talk a little bit about the, how it's delivered as an appliance in a second, but essentially it's a layer two solution that's transparent on the network, right? And essentially all of the traffic would come through and it could be blocked based on IDs. I type of policies.

It can also be deployed in an out of band mode, strictly for monitoring. That would be off of a span port where we're looking at the traffic as it's going through. And we can essentially alert on that traffic.

And again, all of the audit data we can collect through audit agents that are then putting that sort of then putting that audit trail. And those event logs into the, into the audit vault repository.

And again, this is not the solution because it's sitting outside of the Oracle database, works with any databases. So we can work with Microsoft SQL server, IBM DB, two SAP side base, all of these, all of these, this, the solution essentially provides the first layer of defense for all of these database, really for the entire database infrastructure. So I can monitor database activity across all of my databases. I can audit activity coming from the native audit trails from all of my databases and really report out of one repository.

Now the solution itself is delivered on hardened operating system and software appliances. That'll auto configure to the hardware that they're installed on, right? So that allows us to be able to do things like separation of duties, right? Essentially the solution doesn't have to be, you know, maintained by a database group. It can be maintained for example, by a security group. Things like we also have obviously discussed the multi, the multi event alerting, but there's a lot of security that's built into the solution itself. And lastly, performance and scalability.

One of the key things is obviously if we're gonna deploy in line much like the network firewall, we need to be able to keep up with the traffic, right. And a typical, you know, many, I'd say a typical Oracle database tends to see, you know, 10,000 transactions per second, not as an unusual thing, right? So we don't wanna introduce a bottle net for that solution. So it's a very critical that whatever solution we deploy, especially in an inline mode can, can essentially keep up with that.

And the, the reason that we can do this is really the, sort of the special sauce, if you will, of the database firewall, which is the SQL grammar analysis, the approach that we do in terms of defining those whitelists and those blacklist policies that we use for, you know, for determining whether statements should get through or not are based on a very unique approach of analyzing the sequel grammar that allows the decision time to be independent of the number of rules and the policies, right?

So essentially you can have as many rules as, as you want, but the, the evaluation time is gonna be fixed, right? The, the SQL the SQL statements get reduced into what we call clusters, and that allows a fixed level of time for processing. And that's really key because that's what ensures both accuracy, right? So that there's not a lot of false positives or false negatives, and really false positives are, are a really big issue with this type of solution, because think about it 10,000 transactions per second, that's, you know, millions of transactions per day, right?

So even a point, you know, zero, zero, 1% sort of false positive rate, it's literally gonna generate, you know, thousands and thousands of false positives. So that's not acceptable. So accuracy is really critical, both in terms of, you know, the, the viability of the solution, but also in terms of the performance. And of course the audit viral repository itself has to be able to support, you know, hundreds of heterogeneous databases, right?

I mean, the idea is that this is your secure, centralized repository for the entire organization. So all of your database audit trail is gonna go here for really, for, you know, three, four years kind of thing. So scalability and size is, is really critical. We have a number of customers.

We're not, I don't think we have a lot of time to really get into these case studies today, but we have a number of customers that have deployed the solution already diamond resorts, for example, deployed the audit vault solution in order to meet their Sox requirements, auditing a huge amount of data across all of their Oracle and non-oral databases very quickly for Sox compliance. We have, T-Mobile looking at database activity through the database firewall and blocking any unauthorized changes.

And also we have as a TransUnion interactive also using the database firewall to look at, to look at, to look at the traffic, going to their databases and very critical because they're the application that's on the internet for everybody requesting their credit score. So you can imagine how many sequel injection attacks and other kinds of attacks that they're seeing on a daily basis.

And all of these kinds, these organizations and these different industries are looking at these solutions today are using these solutions today to essentially protect your databases and their database infrastructure. And to get additional information, you can go look at the audit vault and database firewall paged for any additional information. And with that I'm done. And we can take any questions that, that this might have. Okay.

Thank you, Alexei. I'm done. It's time to remove to the Q and a session. We have a large number of questions here, so we should try to keep answers relatively short to stay in time. First question was, I think the answer is two to 10 degree, but maybe what have deeper into this a little is audit wall in a sense cm or security information and event management for databases. Yeah. So audit vault is very similar to a SIM for databases. As Martin mentioned earlier, Sims tend to be very generic, right?

A SIM event looks the same, whether it came from a router, whether it came from a system, whereas in, in, in audit vault, we know that we're dealing with databases, right? So we can say, okay, let's see what else this user did.

You know, this is a privileged user. What other databases do they have access on? What other kinds of activities did they do? So really knowing that you're dealing with database provides a different level of forensics.

Now, what I didn't mention is that we do have an integration between the solution and your standard Sims, which allows using the Sims as their alert console. So you would want to be able, for example, if you've got a security operation center, if they've got a SIM and you'd wanna see the auto involved and firewall alert, go to that same sock. So there's a SIM integration that allows that to happen. Okay. Another question I have here is Steve Wal using Oracle database or others, I'm sorry, is, is what was the question? Question wall. So which technologies behind the audit wall?

So Oracle database or whatever Is, yeah, so, so the, within the Oracle audit involved, it's, it's a software appliance. So there is an Oracle database inside of that appliance. You can't access it directly from the perspective of that would make the schema available, but it's really transparent to you, right? Essentially the solution is delivered as a software appliance, which means that, and the reason we deliver just as a quick point, the reason we deliver the solution as a software appliance is because we want customers to be able to scale it horizontally and vertically, right?

We don't want you to have to have a thousand, you know, one U boxes because that's what you need to keep up with your database, right? We want you to be able to scale it vertically, but the fact that there's an Oracle database within the repository is something that, you know, is really transparent from a, from a management standpoint, right. It's really delivered as an appliance with the operating system. Just add hardware, add the CD. And you're good to go. Okay.

Another question, I think you you've touched this say can Oracle audit world output data output data, so, or deliver data alerts reports, etcetera, to be used by corporate cm. So it doesn't integrate in some way with another cm.

Yes, absolutely. Okay. And the last question I have here as of now is, is there any support for big data database structures? Yeah. So that's something that we're looking at, you know, the collector infrastructures I, I hinted at early and I don't think I really, I really got into this, but the collector, the collectors themselves for audit data is, is open, right? So you can set up a, a customized collector for anything that you, that has an audit trail, right? So essentially without any code.

So there's an XML template that you can set up as a plugin for the collectors for audit vault so that you can collect any kind of data into that solution. We're looking at actually collecting audit data from, from big data from unstructured type of, of data. But we already collect data from file systems, as I mentioned earlier. So for example, the ACFS is a file system. That is a journaling file system and has an audit trail built in while we collect that audit trail. Right? So from that standpoint, there's the being able to see who's accessing and auditing big data as well.

What we found is that in terms of the actual reporting type of things, people want structured reports, right? I mean, a lot of our regulatory requirements are really structured reports, type types of data and, and fundamentally audit events are structured, right?

I mean, if you really think about it, an audit event as a who, what way or kind of thing. So audit events are structured now from a, you know, so, so you don't need a big data repository, but you still wanna be able to audit what's happening on your big data appliances and big data systems. So then we, I think we are through all the questions right now. So it's up to me to thank all the participating participants for attending. This could a call webinar and hope to see you at our European identity cloud conference. Thank you for your presentation.

Thank you for, to all the artists for participating. Hope to have you soon again, as a participant in one call webinar. So thank you and Goodbye.