Database Firewall - Build the First Line of Protection

Good afternoon, ladies and Tren. This is Martin Kuppinger of a Cole. Welcome to our cooking. A coal webinar database firewall built the first line of protection. This webinar is supported by Oracle speakers. Today will be me Martin Kuppinger of Ko a Cole and Steve Royal of Oracle. Before we start quick notes around keeping a call upcoming concurrent, and some housekeeping keeping call is an Analyst organization focusing on enterprise it research advisory services, decision support, and networking for it.

Professionals, both vendors and end user organizations through subscription services, where you can access all our research through our advisory services. And through our event, our main event is the European identity conference, which will be held next week. Starting May 10th, 10th to searches May, 2011 Munich, which is co-located with the cloud 2011 conference focusing on cloud security. So it's thence around. So leadership best practice in identity, access management, GRC, and cloud security.

And by the way, we also have a very interesting, some very interesting sessions around database security, and we will have preconference sessions. So we are session referral session around database security specifically, which is help them meet you can through Richard. And I definitely think that it's worth to attend this conference. All the information available, www ID com.com/yeah, I see 2011 hope to see you next week in munix. So let's go forward to the housekeeping, some guidelines from earth, our side for the webinar, you are muted centralist. You don't have to mute our mute yourself.

We can control these features and you don't have to care about these features. At least usually if everything works well and usually works well, we will record the webinar and we will put the recording online, latest tomorrow, as well as the presentations of both speakers. So all the presentations will be available as PDFs for download so that you can share them with your colleagues or whatever, so that you can review them so that you don't have to note everything we are talking about. And finally, Q enable the end.

You can ask questions anytime you can enter the questions using the questions tool and the go to webinar control panel, which you sign the right side of your screen. We'll pick the questions. Usually by the end of the webinar, some cases we might pick a question during the webinar, if it's very appropriate, maybe a note on this, I always recommend that you questions once they come to your mind so that we have a comprehensive list of questions by the end of the webinar. So let's have a look at trend. Yeah. Trend is split into three parts like always, and first part will be my part.

I will talk about database firewalls. They all database governance, security and the strengths and shortcomings of non intrusiveness. When looking at these approaches, second part will be done by Steve mole, Oracle, who will talk about efficient approaches to deploy our database firewall in practice. So that the overall trying third part will be like I've said before, will be the Q and a session given that it's the third webinar in a row. The other Q around database security are available as recordings. And you can run them again to have to, to, to listen to them as well.

If you have missed them, given that it's a third one, there are some slide overlaps at the very first slide. So I have some things to build a big picture in first, which might be known to one to one or other or few who have been, have been attending one of the other webinars.

However, I think it's important to, to really fully understand the, the topic and the later slides for the ones who hadn't been attending until now. So the overall topic I'm I'm looking at is sort of what I would call database governance at the first of our webinars and series of webinars was around database governance. There's also a research route which defines term database governance and talks about what we need in database governance.

So database governance, in fact, or something, which is sort of derived from the corporate governance requirements, which are very generic, very, very, yeah, very high level. Looking at strategic risks, providing book of rules, general policies. Then we have the business chair see, which looks more the operational risks. And then we have the it here.

See, and within the it tier C area we have where we are looking at the it risks. We have a lot of different technologies in there or different approaches in there, which is for example, governance looking at access, right? Access controls, other types of security controls around firewalls and so on. And we have the area of database governance, which specifically looks at how can we protect the information, our database, which is a very important thing, given that most of the critical information in organizations today is held database.

And below that we have supporting technologies, which is the lower left edge. So supporting technologies definitely depend. What are you looking at? And when we look at database governance, then we have a number of different types of database security technologies, including database firewalls, database firewalls are the ones I will look at specifically today.

So why, why should we do this? And why should we look at this? If you look at, and that's a very simple picture, or I'd like to use it, if you look at the different layers, then we have applications. Applications are storing the data and databases. All the things are run on operating system, communicating wider network. And we also have places analytics accessing the database. And I think it's very obvious if you don't protect all these layers, we will always still have an issue in security.

So if you have a good security at the application layer, but no database security in place, we might end up with database administrators or app use technical uses or anyone else doing things with the data which shouldn't be done with the data. We might also end up with business analytics, accessing data, well beyond what should be a large to access.

We might have a situation if you don't protect the operating system layer correctly, where we have some database security in place, but someone who has root access or the database, the operating system level can access the database can delete database files for other things. And so cause harm on this.

So we, we have to look at all these layers and looking at database security in the broader sense, one of the very important things to really protect all the layers we have around our information. And that's what it is about. It's about information security and we can't miss looking at one of these layers. We have to cover all these layers in, in a comprehensive way, including database security. And we have to do it also for all the different use cases. So data address, which is data in the database or exported data and some flat files or anything like this data move.

So when data is passing the network, access by client or whatever and data and use finally. So looking at the applications, access in this data, looking at business analytics, we have to focus on all these use cases and protect databases appropriately, which means we need a set of different database security technologies. That always goes for all of them. As I've said, we have some have done two other webinars before. And so it's probably a good idea to look at the recurring of these webinars because we drill down in some areas much more than this.

When looking specifically at database firewalls, which are very popular approach to do database security. Then in fact, these database firewalls are looking at the transactions which are going from client of whatever type to database and they analyze the action. And it depends on the implementation. It depends on the, the database firewall tool itself, what really happens. So there are some different approaches.

So, and basically the, the most important two approaches are you can run all the traffic, which goes to database through the database firewall, or, or you can just capture the, the traffic. So look at the traffic, but analyze it in alarm, but don't really run all the traffic through the database firewall itself. So I think these are the, the, the most time the demand approaches you have in one case.

So in the first case, the database Farwell in fact will sit here directly on the cable, sort of it's something which really then intercepts the communication between client and database, but something I will cover more in depth, but looking at the yes, aspect of intrusiveness or non-intrusive and what it means for database firewall and for, for choosing the approaches you're looking at overall, it's about identifying, are there things different action which shouldn't occur?

So the most prominent thing for sure is SQL interactions are there, which is a very common type of attacks against database. Are there sequel attacks? If you ask what to do with them, that might be, you could analyze an alarm or you could do other things, as I've said, I will talk about is a little more later on another question, which is frequently asked around database firewalls, should these things look only at inbound and or outbound traffic? So the question is what, what type of traffic to analyze?

So inbound means where is to the database and other types of database command central database. So it's not only a select statement within sequel. It might be all types of SQL statement. It might also be any other type of command sent to a database.

Again, a question of implementation inbound means analyze and, and act on this, depending on the truth and approach that might be really intercepted might be only doing an alarm. Once you have detect something. And it's about in facturing that note or detecting, at least at no alleged command are run against the database. So that could be detective. It could be preventive from a controlled perspective.

Again, that's, that's a question of, of implementation outbound. On the other side means you're looking at what is returned from the database. So looking at the returned results that which then could be used to sort of infer some sort of data leakage prevention, so not allowing specific data to go out.

However, looking at outbound traffic is somewhat more complex than looking at the commands than to the database. So in bouncing is much easier to do because outbound is logically means you, you have to understand what is the database, what are the data, what is allowed to do with this data? What are the access controls? And from my perspective, this is potentially better done at other layers of database security.

So my perspective is that it's more about the inbound, what you really should look at, and if it's really about protecting data and understanding what type of data it is and that's, then it's usually better than at other layers. You might look at specific types of information, credit card numbers, other types of easily to identify PIs or personally identifiable information. But overall, it's more about looking at the inbound traffic. That's also what we see in the market. That inbound is the thing, which so the next question is what to do the most simple approach.

And it's sort of an increasing intrusiveness from the top to the bottom. The small list thesis thing to do is auditing. So logging what happens that might be a very simple thing, which command or rent to the database. The next thing would be inform.

So you, you lock this information, you analyze the information and you inform the defined persons by email, by page, whatever, according to policies you have to find. So that's, I have detective on potential sequel instruction commands. And by this system have a look at it, something like this, which still is a very non-intrusive very detective approach. The next level would be then sort of, of change, which is much more intrusive and which becomes than a preventive control.

In fact, because it's about, they don't log analyzing form, but it's required change the queries. So looking at the queries, which is the fundamental part of what firewalls are doing database firewalls are doing. And then in that case, replacing malicious elements of sequel varies by let's say less critical elements. According to policies there's from an intrusiveness perspective, does obvious risk and doing that because the very not necessarily will return what has been expected.

The other, the highest let's say hardest level of, of interception or for, for reaction could be the interception. So you also might block transaction. According to policies, blocking things is, is always something which is, has a so effect on the application because there will be some results which isn't expected one. And so the more intrusive things are, the more careful you have to be regarding your application.

So, so when defining policies for database firewalls, you have to be definitely careful to avoid situations where you, you do things which affect. So especially false positives affect affect applications, which shouldn't be affected in that way and where you have detected something as being an attack, which wasn't an attack. I think that's the worst case. What could happen. There was all the consequences of such situations. So what are key requirements that I think that's the direct consequence of what I've been talking about? What are the key requirements for database firewalls?

One is reliability ensure that things which are allowed aren't blocked avoided for all positives. The second part is performance ensure that database performance isn't affected, at least isn't affected too much tomorrow.

You, you, you go in between the client and the database itself. So in between the communication path, the more you are at risk of affecting the database performance that's, especially with are, are high performance installations, performance, critical installations. So you have to be very careful around this. On the other hand, security always comes at a price. And so if you want security, you have to pay some price manageability. I think that's another very important point. How can you manage all these policies? And in that case, how can you use a common set of policies?

Not only for a database, but across database for a lot of different tools. And finally, it's about traceability.

So what, what is behind this is that what could happen always can happen is that you, especially, if you're going to, to do it preventive controls, then what could happen is that, that you affect an application. And then the question pops up. What has happened here? Why has it happened? And you need to be able to quickly and easily identify why was some communication, intercepted, changed, whatever.

What had, what, what caused the effect on the application to identify, okay, was it correct? Or wasn't it correct? What a database firewall has done?

So that's, what is this really about looking at these key requirements, I think is very important when looking at database firewalls. So finally this three things to consider reference, or finally there will be one more slide after that, but three important things to consider. So if you look at database firewalls versus application firewalls, well, there's some, sometimes that situation that people are key, okay.

We also might use our application firewalls, however, database firewalls look more specifically of the database transaction, really understand what is happening there and provide a fine crane control. It's not about trusting this application allowed to Excel that, so this trust decepting a, let's say generic type of course screen interaction, but it's really looking granular at different understanding, different SQL statements and other types of database commands. So web application firewalls are from my perspective, trust another layer of protection.

They are complementary to database firewalls. They're not competitive to database firewalls encryption, which is also a topic we have F is addressed in an recent webinar, addresses are types of issues. So that's also complimentary and we end, always end up. It's not about the approach for database security. It's about the right combination of different, different activities, different database security technologies to really enforce a strong level of security and then local attack.

And I think that's another very interesting point database firewalls working outside of the database, firewalls, looking at the network communication. In fact, don't help against local attack.

Again, that's about choosing the right combination of tools. You might also think about a tool which, which really works directly at the local machine.

However, then you have to be very careful regarding performance aspect, a lot of other things. So I think it's something where you really, again, should mainly think about ride combination. So we can start when looking at database security and specifically at database firewalls, the first thing you really should do is define holistic concept for your information security. So not an OS security only, or an application security only, or a database security only concept look at how do these, all these layers work together to enforce information security.

And within this database, security definitely is a very important element. You shouldn't skip that level. You need to have database security in place, database firewalls done, right, helping protecting against an from the outside. They couldn't do it as preventive. They can do it as detective controls, depending on how you used to, how you implement and which tool you choose. And finally, you should design in your holistic content in the context of protect requirements. So also looking at where do I need, which level of security, how do I do things right?

And then decide about technologies and, and almost the, if you do these things right, and then putting in some, some good thought, good S and you should be easily able to achieve, let's say a significant level of security. And, and I think the reason use, if you look at the Sony case, they showed us, it's frequently. It's a lot about, let's say trust. Yeah.

Good, good, good practice and trust, simple understanding. So if passwords are stored and encrypted on database yeah. Nothing else has because that's just a fundamental error done there. Yes. For sure. Some technology might, might have helped to avoid this, but that was sort of an insecurity by design in that case. So my perspective is, think about the different layers, think about what has to be protected, which way find appropriate solutions. Database firewalls definitely can be play a very important role in this and then start doing it.

So these were my, my thoughts around this around database firewalls, their role in database governance and security. I will hand over to Steve right now who will do the second part of the presentation. And we'll talk about approaches to deploy database firewall in practice, Steve, it's your time. Thank you, Martin.

Hello, everybody. Welcome. Thank you for joining the webinar. The I'm the CPO of Oracle database firewall. My name's Steve Moyle. I am the inventor of the technology that powers the Oracle database firewall in the slides that I'm going to talk about today. I'm going to look at very briefly some of the threats to databases and then talk and describe the Oracle database firewall. And I'll be focusing on the technology to efficiently deploy high performance firewalling for an enterprise database environment.

So moving on to looking at the threats to databases and the, the news, hasn't been good over the last few years about data losses from databases and last year's data breach investigations report from Verizon really did pinpoint this. When they analyzed the nearly a thousand breaches that they had seen 900 million or so records were breached as a result of coming from databases themselves. And this is perfectly understandable because as Martin said earlier, the databases hold the most important data in an organization.

So we see here that 92% of records breached in the report came from databases themselves. Although there's been a lot of investment in end user endpoint protection over the last few years, that only account of a very small breach loss rate. And if we have a look at the types of hacking that was behind the large losses from databases, there are three, the use of stolen login, credentials, exploitation of back doors. And then the one that I'd like to focus on here, which is SQL injection, which accounts for nearly 90% of the records lost. So what we wanted do is to protect the database.

One of the largest losses of data was caused by a, a gang who were using secret injection, which is an application programming vulnerability, not as a way of stealing the records straight off, but using it to get control of a database. And in the court case, the details how this gang worked is it was a multi-vector attack. The first entry point was through a low security web facing application, which had a database behind it.

At that point, they had compromised the database host and then used that host as a jump off point to install network sniffers, which were sent through using a malware attack. So quite often the initial entry point for some of these large data breaches comes from a SQL injection attack to take control of network inside the organization. Now Martin's earlier slide showed a layered approach of where defenses are needed. And here at Oracle, we provide many capabilities to construct a secure database environment. And here the database firewall is the first line of event of defense.

Other features focused on auditing access controls, for example, database fault, or going right towards the internals of the database, including, you know, encryption, both in transit, but right at the core of the database. So today I'll be focusing on the monitoring and blocking aspect provided by the database firewall.

So on a single slide, the database firewall is a network device that studies intensively, the network traffic flowing into databases from applications from direct connections, but all of those different points, both considered external to the organization and internal as well. And this information is monitored to prevent unauthorized database access, to ensure that only those with appropriate privilege or roles can connect to the database and prevent illegal access to sensitive data as defined by the policies.

The Oracle database firewall uses a significantly different technology approach in how it determines whether the commands destined to the database are appropriate or not. What the database firewall uses is the entire language of the database. The sequel language uses a grammar there to do an extremely sophisticated analysis on what the commands are going to the database databases themselves are uniquely powerful devices, and they can be asked an infinite number of questions. No two databases are asked the same sets of questions.

So building up their appropriate policies for each and every database is key to a successful deployment of the database firewall. And here the Oracle database firewall with its grammar based analysis allows very accurate baselines to be produced. And Martin talked about wanting to reduce false positive rates.

Actually, it's very key in preventing attackers and secret injections to have a very, very accurate system that doesn't allow false negatives, you know, one single command to a database that accesses the entire credit card table that shouldn't have been issued will export all of the credit card information. So a false negative rate of zero is really what we are aiming to achieve as well. The Oracle database firewall provides different modes of operation that enables policies to perfectly suit the environment for each database that they are defending.

The system is scalable, provides an architecture for high performance and a range of deployment methods. I'll talk a little bit more about each of those in future slides. And ultimately we need to get back to demonstrating governance back to the higher up the organization. So to do this, the system keeps track of information and can be used to deliver a rich reporting environment back to those people in charge of corporate security governance.

So I'd like to talk briefly about the, the two security models that one can use when configuring a database far along it's the, there is the, the white list, the positive security model and the blacklist. I'm gonna focus initially on the positive security model about defining allowed behaviors who is allowed to connect. When are they allowed to connect? Where are they allowed to connect from what applications are they allowed to connect through to the database? That's just one part of the positive security model.

But the second part, and this is to guarantee accuracy at the statement at the command to the database level it's in it's PO it's important to generate a very tight policy based on a baseline of allowed activity or loud commands for the database. And because each database is different. We need a technology that automatically produces such white lists that are focused for each of the applications that need to use the database.

In this case with such a strong white list, you can go into a very strong defensive mode and for any transactions, commands or queries that are outside the policy, they can be instantly rejected and ensuring that the database isn't asked those questions that are outside policy Martin talked a little bit about focusing on the inbound query to the database, compared to the data flow out the outbound flow. It's very important to block all commands, inbound that are out of policy, even if they don't allow data to leap back. And this is because you're protecting the state of the database.

Not all queries on a database are about retrieving information, many of the queries about changing the information or also changing the state of the database. So if you cannot block it on the inbound, it's too late. So we have to focus on inbound firewalling. We must ensure therefore that database only processes the data, how you want it to. So in the slide here, there's an example of a legitimate statement going towards the database and then below the, the line coming from the application shows an example of a SQL injection.

And it's very difficult to define what SQL injections look like in every circumstance, because every application is different. The positive security model allows people to build up very tight baselines and anything outside that baseline outside, outside that policy can then have a reaction from the database firewall. We can also use the negative security model blocking things that we know we don't want to happen on our database. The most productive way here is about blocking connections, not enabling people to connect from different locations in the organization.

Also, we can prevent particular types of commands from being sent through to the database through using this blacklist approach. However, the whitelist approach is the strongest way of getting good security at the statement level in a database firewall. So when it comes to stopping the database, hearing the out of policy interaction, this is the policy enforcement we need to be first.

We need to be sure that we have detected something that is outside of policy and the Oracle database file will having built up this baseline using this automatic technique, relying on the, the actual grammar, the language constructs of the database enables customers to build these superior policies with extreme accuracy. Now we can detect immediately that some statement that is traveling within the database firewall is outside of that policy. And then we can react based on the policy action for statements that are outside policy.

Now, the ultimate objective is to make sure the database does not get issued with that command that's outside policy. And some of the, some of the alternatives one might choose here to stop it receiving would be one would be to kill the network connection. Another would be just to drop that particular command on the net at the network level.

However, we are trying to be as unobtrusive as possible. The firewall is there to protect, but it mustn't reduce the availability of the database to the applications. So to keep the application layer up and the database up, take the statement or the command that's been issued and replace it with something that's completely benign. Something that we know is not going to return any results back to the application.

This gives ultimate flexibility in keeping the network level established, keeping those connections established between the application of database, but without letting the out of policy statement be issued to the database. Now, this level of statement, substitution can only be achieved effectively with high levels of accuracy. And at the core of the Oracle database firewall, it gets its accuracy from this grammar analysis. So the three, the three outcomes that you can have with the firewall when it sees a statement is pass it straight through.

The second one is to pass it straight through and send an alert or log a copy of the statement. And the third one is to block it. Once we have sent our alerts and done our logging, if it's, if the policy says this is a particularly sensitive table, we want to log all interactions with it. We have a rich reporting interface that can draw on the data warehouse that has stored all of the logged, all of the logged information.

Now, this allows us to produce reports that to meet particular regulatory controls, for instance, or provide people with customized reports to send up through their corporate governance chain. Now, as we are logging the statements themselves from the network, we will often get to observe sensitive data being carried as payload, either in the queries or in the inserts or the updates, not all of that information is appropriate to be sent through the reporting and the, the, the management system.

So the final point here on this slide is that each of the log statements can be sanitized and have the personally identifiable information or the sensitive information redacted or removed at source before it goes through the logging system. So that's a, a, a, a summary of the reporting system. So architecturally, the firewalls can sit either in line or out of band.

Martin talked about the monitoring only capability in this case, this simple way of doing this is to configure network switch, to provide a duplicate of the network stream, going to the database of a span port or installing a network tap. The, the firewall can then in that case record all of the information on the network, but take note active action for blocking putting the firewall in line between the applications and the, and the database by installing it as a network bridge.

And this gives the ability of actually performing some blocking, taking some control of the statements the firewalls themselves are made from industry standard components. The operating system is Oracle's enterprise Linux it's installed onto customer hardware, supporting any hardware that's supported by O can be used.

There's a separate component for managing the, the firewalls and sales, managing the policy, and also managing the logs that come from the individual firewalls, the firewalls, a high performance, the core approach allows up to tens and tens of thousands of statements per second, to go through the, the network bridge, even on fairly modest tool based hardware. And this is due to the core approach of the system. One further thing is that the firewall does not require any development changes to either the database or the application side. And it's not just an Oracle database supporting product.

It supports a range of other vendor databases. And in fact, one firewall can be used in a mixed mode supporting multiple databases and multiple vendors.

So quick, quick summary here, the, the, the firewall here is to act as the first line of defense. It is different, as Martin said, from a web application firewall that sits in front of an application, it has more focus. It focuses entirely on the database traffic, whereas quite often the web application firewall is trying to guess somewhat what sorts of commands might be going through to the database. The Oracle database firewall does have the ability to link up with web application firewall and to share the intelligence between two such devices.

The key things behind the database firewall is it's highly accurate and highly performance, a grammar based analysis, removing costly, false positives, and more importantly, being able to detect SQL injections immediately preventing false negatives. It's a scalable architecture and fits. It can be deployed in multiple, multiple modes and schemes to give a flexible deployment across the enterprise wide architecture. So it's just the first layer in Oracle's defense in depth, depth strategy, Oracle provide a range of comprehensive security features.

Many of whom are transparent, requiring no changes to either the applications or the databases in a simple and cost effective way to deploy. If you want more information about the Oracle database firewall or any of the Oracle database security products, go to oracle.com go to slash database slash security or go to slash database firewall. Thank you very much. I'll hand back to Martin.

Okay, Steve. Thank you. I'll switch over to my presentation again and thank you for this great presentation given by you all details. We have the first questions here and like always ask the attendees to enter their questions right now so that we can do our Q a session. Let's start with the first question I have here. DB firewall and policy enforcement is the same as virtual private database slash R LS.

No, the firewall is a different, different security, different security product, and solves a different use case for virtual private databases. The first thing to, to notice is virtual private database is for an Oracle only database. Whereas the database firewall is for different vendor databases as well as Oracles. The second point is that the virtual private database is a, a segregation of data technology within a single database. Whereas a database firewall is a network level defense. I would describe it like an intrusion prevention system for databases. Okay.

Another question I have here is if there's no change in applications needed to deploy the firewall, where does the firewall sit in the network? Topology? I think you've shown the inbound and higher, but maybe you can chat about again. Yes. So consider that the, the application is on a different, different physical device than the database, then to perform a firewall in between the application. The database requires it's in one of the network segments that connects the, the application, the database. We effectively cut that cable into two pieces.

We put the database firewall in, in the space between the two cables. And then we put the two cables, one on either side of the firewall. So the database firewall, at least in blocking an enforcement mode is a network bridge. And we would recommend that we, that the database be put as close as possible to the database. So if the file will be put as close as possible to the database, almost simplest would be to unplug the network table that goes into the database, plug it into the firewall, and then plug a new table from the firewall into the database. Okay.

Another question is the firewall limited specific Oracle versions. No there's is no limits that it supports all current, currently supported Oracle databases right up to the, the present release of, of the product. Okay. Another question is, can you compare Oracle database firewalls firewall? IBM guardian, always little bit difficult question. And so it's up to you whether you want to do it or not. They've the guardian and other firewalls that are out there are similar in that they are network level devices. They are often powered by different technology.

I guess the, the key difference for the Oracle database firewall and other firewalls database firewalls on the market is the level of accuracy. So the core technology enables the system to be deployed at a real time. Firewall. It blocks the statement before it gets to the database, rather than disabling privileges for statements that have been deemed to be out of policy. So it's accuracy.

And, and I guess the second thing is the way in which the policies are created. So this automatic creation of highly accurate baseline is something that's unique to the Oracle database pharma. Okay. Is there any delay for my SQL when using Oracle database firewall? So what was the question again, Martin? Is there any delay for the SQL statements when using Oracle database firewall Any delays? Okay.

So if the, if the question is what is the, the latency that's introduced? The, the latency is very, very much lower than a millisecond. Okay. Sounds like there potentially there can be a single database firewall in the primary data center for all database hosts, as long as they are in the same network. Correct? That is correct, but it is very rare to find all of the databases on the same segment database firewalls are different from other types of firewalls on other types of enterprise gateway security products. Yeah.

When it comes to a spam gateway, you just have one entry point into the organization where all the email traffic goes through, databases in organizations are spread far and wide. It is not uncommon to find organization with 10,000 or more databases. And they don't all live on the one segment.

So for those databases that are on the one segment, yes, we can cover that off with a single database firewall or, or two in high availability configuration, but more often than not, we find that they are scattered around the organization, requir a range of database firewalls, which then are coordinated centrally through the database firewall management server. Okay. Does the database firewall also protect electrical standby databases? So as long as the databases are on the network, then they can also be protected.

We have many people running configurations where they have active standby databases. They also have active standby data sensors and the different deployments modes for the Oracle database firewall support those. Okay. Any further questions from the audience? Another question is whether there are some, some S around technical installation database firewalls in practice avail of, I assume that you have something at the Oracle website, the link you've mentioned before, which is, I think I send your presentation, which will be available for download, Correct? Yes.

So there is documentation on Oracle's website. The product itself is available for download. So people can feel free to download it, register, download, and try the system out for themselves.

Okay, great. How is the replacement of bad with safe one done? Does it mean that the administrator should define sort of white or blackness for every possibility, or how do you deal with practice? The there's a range of granularity that one can use can either make a, a blanket rule that anything outside policy is replaced with a particular substitution or write down to individual types of statements. What we call clusters, the smallest pieces of policy for this particular type of statement. I want it replaced with this particular substitute.

So there's a, there's a range of, of granularity there, and people can configure it the way that they wish it's key that the, the statements are, for example, for the same type of database that you are defending. There's no point trying to substitute a bad Oracle statement with a good Microsoft SQL statement, of course, but within those sorts of constraints, almost anything can be achieved. Okay. Theoretical database, Oracle firewall, certified database cert firewall certified suite, and the database used there. The application level certification is an ongoing program.

I'm not sure where we are with eBusiness suite. So, but the database firewall definitely works within an eBusiness suite environment. We have customers using that. So I guess it comes down to what the word certification means. Does it work most definitely. You need business suite, Which the size of the hardware for the database firewall for custom database is three, five per second. So what would be your recommendation for that?

Oh, perhaps I could respond to that one offline. I, it, it doesn't sound like a very big hardware requirement. So I would, if we had small, medium and large, that would be in this small range. Okay. This high firewall, is it a separate Unix process or is it somewhat where embedded into the database? Yes. So I think we, we have to be clear that the firewall is not part of the database that it is protecting. It's a network device it's completely off the database host.

So yeah, it's completely separate, not only a separate process, but a separate piece of hardware. Okay.

Finally, is there a database associated with database firewall to store all the information? Yes. So the management server that aggregates all of the logged traffic that has an Oracle database inside it, but the, the firewalls themselves are just interested in the network stream. Now it's more, more about what database is used to store information collected and so on logs and all that type of stuff.

Yes, that's right. So that's an Oracle database on the management server When still using Oracle advanced security and an encryption. Does it make sense? And is it important to implement Oracle firewall as well?

It, yeah. So encryption, isn't the solution to all problems. For example, a SQL injection will travel on the wire encrypted will interact with encrypted data inside a database, and then send back the results set, which shouldn't be leaving the database encrypted and the application layer then expands that out.

So yes, we, we do need to make sure that the, the firewall is in that environment as well. Okay. Any other questions from the audience? So we had a pretty big number of questions. If there are no first questions, I would like, oh, there's not a question coming in. So how do these things around database firewall apply to other types of solutions like open source databases? So does it work with other types of database also from the open source space?

The, the support for, for the Oracle database firewall is currently for Oracle, Microsoft SQL server Sybase, and IBM DB two, there is a roadmap for supporting other databases, but I can't talk about those at the moment. Okay. So thank you to you, Steve, and thank you to the audience for participating in a call webinar and asking a lot of questions. And I hope to have you again in one of our upcoming call webinars and especially hope to see you at European conference next week. Bye.