Hello everybody. And welcome back from the coffee break. Was there some, something bad in the coffee that, or was it so excellent. Anyway, we'll just start away. This is the last official session before the closing keynote in this auditorium, and it's all about securing big data and the focus will be database firewalls, how to want security for enterprise data and together with me on stage our Dr. Steve Mo and naturally Martin copy him. We'll just proceed as followed. I'll just hand over to Martin right away. So he can give us a little overview, how database governance and database security maps into the copy, our call it model. And I'll just give you a little overview of what else to take care of using database governance and database security. And the major part of the whole session will be done by Dr. Steve Moore afterwards. So where are we today with security? Enterprise governance usually targets all the enterprise wide policies and the strategic risk and stuff. The business GRC is a little bit more focused. This is what we are more used to. This has a focus on operational risk, but both are rather not so much it focused. So where's the link to database firewalls. Why do we have that as a track here? Well, it's called database governance who would've guessed that and how this actually relates to the copy and call it model the master himself. Martin will point out in a few minutes.
Yeah, but you, I think you have another slide here. Oh,
See, ah, sorry. I forgot that. So for those of you who haven't heard about database governance itself, it's just the set of policies, procedures, and especially the organizational structures and practices that help you keep your database intact, integrity, Safed, and the security maintained that should help you to ensure that the execution of the database and the database related activities is according to defined strategies and not just something that people call DBAs do. So.
Yeah. How does that relate? And if you look at our, our paradigm, I think it's hello to everybody who I haven't said hello in one of the other sessions, if you, if you look at the thing. So our paradigm's really very much about saying, okay, we have a lot of services and we need to secure these service. And I think if you look at the, let's say the middle of the thing, where we have information security and on the right side where it's about it, governance, including information governance, then I think it becomes pretty obvious that looking at information and, and protecting information is a very important thing. So overall I'm, I'm, I'm a great believer in that. It makes more sense to focus on how can I secure information then how can I secure a system? And I would say, if you look at all the things we have a database security, it's probably both of it.
So it's about securing database systems. It's about also securing the information itself. So if I look at your portfolio, I think you have both of the things in there. And, and I think probably will need both because we have, so as long as we produce the things ourselves on premise, it's probably more about securing the system as well. So that's where this fits in pretty much when we look at the information itself and how does it flow and it's more on the service level. So how do we really secure this information, but overall, and I think that's, that's one of the things I've written about a lot about, and I've talked a lot about over the last years, over the course of last years, I think one of the very important things to understand always, or to keep in mind always is good. Security is sort of holistic security from Richard approach.
I remember Sebastian of frequently had a slide with a picture with a barrier, or was it barrier on a road? And the cars always were driving just around the barrier because they could. And so I think that's, that's the point. If you just solve one issue, you, you are in Ghana. I think if you look at, at all this stuff of information security and information governance, large portion of the data is where it is a database. And so if we don't protect them, it doesn't solve the entire problem. So we have to look at this as part of the entire story. It's a pretty simple database security doesn't solve all of our information security problems, but on the other hand, without informa database security, we definitely are notable to solve our information security issues. Overall, the example I always like to bring is this typical, you know, you put a lot of efforts in using those things, like, let's say a PPG C X control and other things to ensure to secure as SAP P environment.
And you didn't care about the underlying database, which most likely will be from Oracle or someone, but pretty frequently from Oracle. So what did you really achieve? Yeah, a little, I would say probably some people can't, some less people might use sub all, but that's it. And that's not sufficient. And for sure, also, if you then perfectly secure database, forget about securing your units operating system, and the roots can do what I want to do, then you again have lost. And so I think we're looking at information security and that's something we, you look at some of those things we've written around the it paradigm, which we will do diving deeper. Then these things become very obvious. This is one very essential part of it when to understand where's my information, how do ideal? This is secured probably, and we need to do it on all levels for services.
So the way the information itself and for the systems, when we look at the on-premise part, it is a part it's not the only part. And for sure, also we have to look on how to secure data in the cloud when we move it around data, spread all these things. So it's, I would say a logical part of the entire picture. And so I think there's a good reason because we are not an identity access management Analyst company. I would say we are focused really on this bigger picture and information security is a key piece. And so there's a good reason why we are talking about database governance or database security and even database firewalls here now.
Okay. Thanks so much, Martin. What I'd like to do next is just show you a little bit how this can be drilled down a bit. How, how the context for database governance really looks like, and it has many, many facets for those being shown here. So you have the corporate governance perspective. You have the business GRC perspective, you have the it GRC perspective and you have supporting technologies. So from a corporate governance perspective, what you need in database governance is you need a book of rules. You need something where administrators, where people could actually look up of how to set up the database, where to put it and how to work with it. Some general policies and some indication that helps them identify what strategic risk will be involved, deploying that database with the data that is specified to go into it, the business GRC perspective then should allow them to evaluate what the operational risk is that comes with deploying that database, how the controlled monitoring could be made continuous and not just an audit every other year, or just when an auditor internal revision just comes in.
So process and risk controls need to be in place and they need to be adapted to what the operational risk really is. So it then would be it GRC stuff that actually relates to the it risks that we are facing in having the servers that run as database servers, the technology that actually provides us with the database that we need, and we need to take care that all the access governance aspects are taken care of, that the security controls are in place. And that what we do around security in and around the database is actually reflected in our security management strategy. And that it is reflected in our security management tools and database governance itself must be a part of your, it G C approach. Finally, they're supporting technologies because we learned over the years that there is an approach that's called defense in depth, but it usually ends up in providing you with loads and loads of events and stuff that ends up unread in some log databases, and nobody ever looks at it.
So we have those security and event management technologies that definitely are needed to regain overview of what's happening inside here. It GRC, we need to have again, access governance because those technologies need to be monitored and accessed themselves. The supporting technologies include provisioning and the core identity management technologies, because we don't want to give anybody, everybody access to everything in a database and the database security technologies themselves that have been surfacing over the last few years. So to drill down and actually show that there is still some need for improvement here. Some figures about the database governance status today. And I must say, it looks like it's still very bad. Although these figures are one and a half years old, I doubt that they have changed dramatically to the positive site. In preparation to this speech, I've talked to a few Oracle security database administrators and some of what they just provided as feedback flew into that sort of chart.
So we have lots of different attacks, lots of different breaches, some of which are directly related to the database, some of which are related to technologies that surrounds the database. So the data can still be read and tempered with, by any system or admin who has access to the database. So we definitely need, still need to take care of that. The DBAs still are sort of a problem. There are tools to keep that under the hood, but it's still very hard to deploy. Still few organizations have actually technology in place. What worries me is that users still are very easily able to bypass all the security policies that have been put into the applications will dig a little bit deeper into that later on. And that the abuse of privileges is still not very well detected when you deploy such a database. So lots of stuff to do, lots of problems to face and lots of ways to do that.
So when we take a look at how data actually can be attacked or read using different vectors, there's the standard way you just use your application interface and you should have a distinction between the user and admin accounts for that application, but it's the application. And we'll get back to that a little later, the DBA way. Well, there is a DBMS interface. Everybody who is DBA can just fool around with anything there. So you should definitely take care of introducing processes and technology that keeps everybody from using DBA to do something with your DBMS. Well, and then there's the network way. The servers, the database servers are somewhere on your network. Hopefully they're not in the DMZ. Hopefully they're not directly internet facing, but somewhere in the back end behind some sort of regular network follow, but still they are reachable through the network. That's what they're for.
The problem is usually nobody cares about from where this database is actually accessible. So some general rules of how can somebody connect to the database server from where would definitely help us get rid of some of the problems last but not least. There's a direct way. If I have access to the operating system that hosts the database. Well, in most cases, that means I'm pretty much open to do anything with that database that I like. So operating system privileges need to be granularly managed in order to keep the admins that are responsible for managing the operating system from tempering, with the database. So there are lots of places and directions to start your attacks from. And that usually means that we have different attack vectors to take care of. And one of those are definitely the users in the applications and the DBA users today.
Most people would say, yeah, whoa, we are in an identity management conference here. And there are, are pieces like privilege, identity, access, user management. And they will take care of everything around that. And that's not really true. There is more to it. There are the system and CIS accounts, and there are well recommendations that you should disable those, but nobody guarantees you that your database runs after you deactivate those system accounts. So it's a little bit by you. You, you just kind of go there and say, okay, that's best practice. I deactivated. And then business comes back and say, Hey, my, my database doesn't work anymore. So there's more to it also granting and revoking the public access to the database is a little bit tricky. You need to take care that the database still works afterwards because some of the databases just expect to be able to read public.
And if it's not there, they just crash. Others would say that, oh, well, there's encryption just encrypt all the databases and your fine, you can encrypt columns. You could encrypt rows tables and that will do the trick. Well, yes, maybe for the issue where the OS admin connects directly to the server and tries to read something. So he finds all encrypted, garbage in the tables. Nice. But what about the application? The application needs the right to decrypt and it's decrypted on the way. So the data at rest may be protected, but the data in flow, the data that you are actually seeing in your environment, in your application, well, it's unencrypted. So it's not a solution for everything. All are valid salts, but it's not going to get everything done. So where to start, you absolutely need that holistic approach that Martin was talking about.
There is no such thing as, oh yeah. We, we do everything around operating system security. We do everything around app security and the database security. You need to have a joint approach. You really need to think about the attack vectors that are relevant for you, the risks that are relevant for you and create your own database governance around that you would need to pick and choose those methods that are the best for you. Database security itself is an important element. There encryption is definitely an important element, but it just doesn't help everywhere. And for your own environment, it's absolutely necessary that you come up with your own concepts and see what your own requirements are, and then make a decision about the technologies that will help you keep what you describe in your database. Governance concepts in place, theistic approach really is needed. And I switched that photo because Martin was referring to that or locker that gate where everybody was driving around.
I think it got a little bit overused. This one is, I think absolutely the same. You have that really nice metal garden door. You have it in deep concrete, but the security that's represented by the bushes around it. Well, it's minimalistic. If you come back in like five or 10 years, it might be sufficient protection for that garden, but right now they locked and bolted the door. But everything around it is not really what you would expect for holistic security. And that brings us to the point where I like to hand over to Steve. And I am very happy to have the opportunity to hear a little bit more about what database firewalls can and cannot do to actually help us get that holistic approach. So hand over to you, Steve. Yeah.
Thank you everybody. Thank you for coming to this final session today. I want to build on what Sebastian has just said in that there is no single tool or technology to protect your assets. And in particular, there's no single tool or technology to protect your database. It's a defense in depth strategy that needs to be deployed in the appropriate context of your systems. But I'm going to talk today about one piece in that defense in depth strategy. I'm gonna talk about database firewalls. I'm gonna talk specifically about the Oracle database firewall towards the end of the talk. But first I'd like to motivate one of the firewall use cases from some real world breach scenarios. How many of you have heard about viruses that can infect your workstation and still your passwords? Okay. I think that's about a a hundred percent of the people who were paying attention to the question.
How many of you have heard about an attack vector called SQL injection? Okay, very good. I will talk a bit in detail about SQL injection. It is just one use case that database firewalls help to prevent. But I think if we have a look at the intricacies of that particular attack, you'll start to understand the broader capabilities of a database firewall. So in 2010, the Verizon data breaches report, the analysis showed that although database servers only accounted for 25% of the breaches, those breaches accounted for over 90% of the records stolen. And of course, that makes sense. If I'm an attacker, I want to get as many records for my hack as much bang for the buck. And I'm going to go to the places that hold the most records and that hold the most valuable records. And these are going to be the databases.
It's not really worth my time as an attacker to start stealing information off individual desktops because it's so diffuse and diverse. So in their report, Verizon describes SQL injection as being one of the main causes for these breaches on databases that combined with use of stolen login credentials, accounted for the majority of the stolen records. And I quite like this quotation here, the versatility and effectiveness of SQL injection makes it a multi-tool of choice among cyber criminals. The understanding in the vulnerability assessment industry is that somewhere between 30 and 50% of web facing applications that talk to a database backend are vulnerable to a SQL injection. And there's been research in places like IBM that say presented with a website and attacker with the appropriate skills will be able to find some entry point to apply their SQL injection two in about three attempts. So let's say half of the websites are, are vulnerable.
It'll only take an attacker up to about three attempts to find a nice place to inject through. So what is it and why does it occur? Well, actually it's not about the database as it happens. The vulnerability is at the application. It is poor standards of programming at the application layer that allows these injections through, but actually the root cause here is the level of trust between the application and the database. You built the application to talk to the database, the database implicitly trusts, everything that is sent from the application. The application is effectively an authenticated user. It's allowed to query the database and therefore the database replies with an answer to all queries that the application manages to get through and quite often, and this is a very disappointing fact. The applications are written to connect with much too high level of privilege to the database.
The number of deployments that I've seen of firewalls into a data, into an enterprise about 50% of them, the applications are connecting in with CS or root privilege on the database. And in fact, the access controls are at the application layer, not at the database. So anyone who can misuse the application will manage to get the database to reply with results that the developers wouldn't have expected. So here we have a small SQL statement that is being sent from the application to the database. And in this case, it's a good statement. It's normal. It's what we would expect to see. However, if instead of typing in the entry field, which is in green P H E 8, 1 31, the user puts into that field in the application, what's written in red there, union select card number, customer ID com zero from orders. The application logic assembles the query to the database at runtime.
And because it's coming from the application, the database trusts it and will answer that particular query. So this is how it typically works. The application layer is poorly programmed. It doesn't check the validity of inputs coming from untrustable users of the system, anyone outside the trust boundary of the application. And it just takes the entries and puts them directly into a template that it's been programmed. And that template is sent to the database and the records are displayed or used by the application. So that's how a, a normal SQL statement is assembled. How about an abnormal one? So instead of putting in a valid, a valid product code, this particularly longer sequence of characters, this in fact happens to be a, a fragment of sequel. Text is parachuted into the template. The template is sent off at the database answers, but now this time the results set includes what look like credit card numbers.
And they are now just as applications are poorly programmed to validate their inputs. Many of them are also poorly programmed to validate the results coming from the database. In fact, quite often the application layer just says to the database, having just sent it a query, how many results do you have for me? How many columns are there? What are the column types? Just a moment. I will create a table, usually an HTML, and as the records come back, populate them. So quite often the results are blindly transmitted straight back to the user. And in this case, we have payment card details leaking out of our application. Well, it all looks very the theoretical. You say, what does it actually look like to an attacker? Well, here's a webpage for buying goods online here with the, the injected fragment through, into the application, through the web, the web browser, and back come the payment card details.
And you'll see that the application actually formats an ID number as currency, because it really doesn't care. It sees an integer, oh, that was in the currency column. And back it comes well act. We think that stealing the records through where the interactions might be one of the motivations of the attacker, but actually it gets much worse than that because you can achieve almost anything with a sequel injection attack, and it's possible to even take complete control of the database host. So in this particular example, I'm not showing you the injection fragments, but the attacker has managed to get access to the operating system of the database server at the privilege that the database is running on that server, usually very high privilege has managed to get the database server, to upload a copy of a tool called Netcat. It's known as the Swiss army knife of the internet.
It allows you to connect two ends anywhere on the planet together. And then by running a copy of Netcat at his local machine, the attacker can shell directly into the database. At this point, I want to bring up a court document, a PDF of a court document from United States district of New Jersey. So I don't want to tell you in the abstract about how SQL injection works. Let's have a look at a particular case that came to court in 2009. So this is a court document. It's all very simply formatted. The first page talks about three defendants. The first defendant is Albert Gonzales also goes by. The name is Jaguar 17 and two other defendants probably located in Russia, hacker one and hacker two. And then there's the fourth person on the page, the conspiracy order whose turn state evidence. So on the next page of the PDF document,
Can we go back to the PDF? Ah, okay. Thank you very much. So you are sitting in court, there's a judge and you have to help the judge understand this, okay. Methods of hacking utilized by defendants point E structured query language SQL was a computer programming language designed to retrieve a managed data on computer databases. At the very beginning, you have to be able to tell the, the judge about SQL and databases point F SQL injection attacks were methods of hack into and gaining unauthorized access to computers connected to the internet. The next point you have to be able to teach the judge about a sequel injection SQL injection through series of instructions used by hackers in furtherance of secret injection attacks. Malware was malicious computer software programmed to among other things, identify store and export information on computers that were hacked, including information such as credit and debit card numbers and corresponding personal identification, information of cardholders, the card data, as well as to avoid detection by antivirus programs, running on those computers.
I'll come back a little more and explain exactly how this attack worked. Let's have a look at the victims, Heartland payment services, one of the world's largest credit and debit card payment processing companies process millions of credit and debit transactions daily beginning on or about December 26th, 2007. Hartland was a victim of a secret injection attack on its corporate computer network that resulted in malware being placed on its payment processing system and the theft of more than approximately 130 million credit and debit card numbers and corresponding card data. So victim one, 130 million victim, 2 7 11, doesn't say how many victim, three Hannaford brothers, 4.2 million credit and debit card numbers, another unmanned company and so on. So what was the attack vector here? You would expect that someone like Heartland payment systems, credit card processes, would've invested a lot on security and database security. And in fact, they did, however their investment depended on whether it was seen as a high security site or a low security system.
And they had low security systems, web facing low security systems attached to database backends, where they hadn't spent as much money or time in getting the security properties. Right. And it was through those systems that Gonzales and his colleagues managed to get operating system access footprint into their corporate network. From that vantage point could see what the defenses were, what AV and anti malware systems were running. And then they constructed custom malware undetectable by those technologies that were protecting the system and installed effectively a network sniffer into their high security environment, which was harvesting the information as it was going past on the network. It took them six months to find the sniffer. It took three different audit teams to find it took the third team to find it. And the original tip off that something bad was going on in their network came from a bank in another continent who had correlated card fraud to that particular organization.
So SQL injection in this case, wasn't the only tool that was used. It's a multifaceted attack, but very often used as the first entry point. So if I go back to my slides, so one of the challenges with SQL injection is that there's effectively an infinite number of ways of causing harm. If you find a SQL injection hole, it's very difficult to specify what an injection is because there are many ways of getting the same effect to occur at the database. And although union was part of the injection that was shown for the first example, union being a sequel, keyword is not always bad and can be considered normal. So systems that just look for particular keywords are going to false alarm at a high rate. And even still, there are ways of obfuscating these keywords that will avoid a signature detection engine. And in fact, signature-based database firewalls end up making too many errors.
They let in, well, they, they give you too many false positive alarms. They say that they are attacks when they are not to the point where you disregard them and even worse. They silently let through attacks if they're based on particularly regular expression type signature technology. So I want to start at a, at having motivates. I wanna start at a sort of a higher level and talk about what a database firewall is and why it is different from a network firewall, which is there to control the flow of traffic between networks and hosts. A database firewall is specifically designed to control the flow at the network into an out of a database. And the key difference here between a traditional firewall is that the database firewall must really understand what it is that the database is being asked. It must be able to understand the language of the database SQL.
So it's quite a challenging environment to be on the network and protecting a database. Most organizations have more than one database vendor, not just Oracle, but there will be Microsoft IBM Sybase and other databases across their estate and different versions of each of those database vendors. Plus, if you look at it at the application side, different versions of software that attaches attaches to the database I went to, actually, it was a German company last year and talking to their security team, they said they had somewhere between 5,000 and 10,000 databases. Actually you can understand that's the biggest problem is that they don't know how many databases they have to secure on the network still itself. There there's a challenge as to the wonderful array in which people build up their network, architectures switched flat. Are they using virtualization, physical hardware, and a firewall has to be able to sit inside those environments.
And then there's other architectural issues, high availability and so on. So that's at the sort of database of the network end, but then there are all these different applications that are connecting to databases. So even if we both have the same Oracle database management server, the applications that connect and run against those databases vary drastically. So I'd like to talk a little bit about the Oracle database firewall. It's effectively a network device that sits in the network stream, and we would recommend it sits immediately in front of your databases to prevent out of policy activity, being sent across a network to your databases. The one of the key features of the, the firewall is that it uses a white listing approach based on understanding the complete SQL grammar. And this gives a high accuracy and also highly scalable approach to protecting the database. And it can be used in two modes.
One is an inline blocking mode where it actually prevents out of policy statements arriving at the database, but it can also be used in an out of band monitoring mode as well. And I'll show you that in an architectural diagram shortly. So the complexities of the, the different database environments and the fact that there are an infinite number of SQL statements that you could write using the, the grammar for SQL makes it a real challenge for signature based systems to detect what is legitimate traffic and what is not. In fact, operators of systems spend all their time writing rules to tune the, the firewall that they become very much a difficult device to manage. So just straightforward pattern matching is not going to be enough. And the error rates tend to be intolerable. So what is the, the database has that we can use as part of our defense?
Well, the database has this thing called the language, the SQL language, and with some sophisticated technology, it's possible to identify what part of that language space, that particular applications and particular users need for getting their job done. And this is the basis for building up the right lists for allowing access, allowing questions to the database. And with that in place, it's possible to detect immediately any statement that's outside that set of wireless and when it comes to SQL injection, but actually it's not just SQL injection. It's any query issued to the database that's outside the policy. It can be blocked instantly, and there are some good computational properties of this algorithm that it makes sure that as your rule base increases, as your policy gets more complicated, there's no deterioration in performance of the, of the lookup. So how does this positive security model work?
The allowed behavior is designed defined usually through a process of monitoring an existing application, but actually it's also can be defined in the pre live environment of your applications so that, you know, before you turn them into a live production mode, exactly what those applications need from the database. And you can get a preapproved set of statements or statement classes for your policy. Now, this process is highly automated. Just watch the application, talking to the database and we will build up these white lists for you automatically. We have one customer who has a relatively modest trading system in New York. They do about three 30 million statements a day on this one, one database actually watching the 30 million. It only boils down to about 300 types of behaviors. And very quickly you can build up your white list, given that you only need to study the 300 different behaviors on top of this, there are other factors, including the username, the time of day, the network IP address that applications are coming in from to build up a very rich policy.
And the key thing here is anything that's out of policy is instantly detected as being out of policy and you can apply one of numerous actions. One might be just to log the out of policy statement for reporting, or you might choose to actually block it from ever arriving at the database. So that's the positive security model for those that like whitelists or the negative security model, there are ways in which you can specify policy in advance to block certain activities. Typically, this is done with things like DBA access. We only want DBAs to access from particular workstations using particular applications. And during office hours, if, for example, a DBAs credentials got compromised, say through a spearing attack, then someone coming from the web and getting access say to a, a web server would not be able to issue any DBA like activity.
And when it comes to DBAs, they can be quite apprehensive. At first, when they see a firewall going in, they want to make sure that the firewall doesn't stop them doing their job. And normally the policies are configured in a way that they can do anything they like within the database, but everything they do gets independently logged for reporting later. So here's the challenge. What happens when you've determined that a query on the database or a statement is out of policy and you don't want it to arrive at your database, what do you do? Well, it's a technical challenge. Do you just hang up the network, break the connection to the database? Well, actually, sometimes applications are a bit, are a bit brittle around those connections and can take a while to reestablish that doesn't always work. Maybe you might just not transmit those network packets with that statement in it that may or may not work depending on the application.
The most elegant way of doing it is what we call in the product statement substitution. So this means that a, an out of policy query is replaced with something that is benign. Typically something that the database won't provide any results for. And this enables both the application, the database to stay alive, stay up, but without the database ever being asked to change state or deliver results that are out of policy. Finally, the, the database firewall collects lots of logs of statements that have traveled across the network, depending on the way the policy is configured and having collected that information, it gives you a very rich, independent forensic forensic resource, and also for regular reporting, typically for compliance purposes, the architecture and deployment for the, the database firewall comes in a two tier arrangement, which I'll show on the next slide with, at the top tier being a central management server that provides a, an aggregation point for logging and reporting, but also a central location for doing the administration of all the firewalls.
So just talk a little bit about the firewall and its deployment. We call it a database firewall, but you might also want to think of it as what I would call a backside application firewall. It's effectively protecting your database from misuse of applications. So mentally you can think of it either as an application firewall that sits on the back of the application or sitting right up close in the last leg, in the chain to the database itself. So the Oracle database file is not just for Oracle databases. It supports numerous other databases. My SQL DB, two Microsoft SQL server and Sybase. It is a physical device it's sold as a virtual appliance or a software appliance. You determine the appropriate hardware for the, the, the use case for the environment. And that hardware then is used, taken over completely as a bare metal install of the Oracle database firewall.
When you're finished, you have a hardened network device that can be used to protect your databases. There are two main modes of deployment in the network. One is as a network bridge in front of the database. So that requires you effectively to cut the cable going into the database and splice that either side of the firewall, the other mode, which is non-intrusive is to send a copy of the database traffic from a network switch, using a span port in, and that will allow you to use the firewall in monitoring mode. There's no change to your database required. There's no change to your applications. The change only occurs at your networking layer. The underlying software stack includes the Oracle enterprise Linux as the operating system on the firewall, but that's really not important. The firewalls themselves then send through a separate management network information back to the management server. So that's how it works. You can have multiple databases protected by a single database firewall. It's only a capacity planning and network architecture issue. You can have Oracle databases and Microsoft SQL server databases, all being protected together by the one Oracle database firewall. And for those of you that are interested, the licensing model is done on per processor of database that the firewall is protecting.
So just to summarize quickly, the database firewall is part of a broader defense in depth strategy for protecting databases, but it's a first line of defense and is very effective at keeping out things like SQL injection attacks, but that's not, its only use case. The technology provides a highly accurate and highly scalable way of defining and executing policy. In real time, it's transparent. You don't have to make software changes at your application level or at your database level and as a corollary of making strong protection in your database and monitoring that strong protection, you get a cost effective way of demonstrating compliance in your regulatory framework. That was all I had to say. We've got some time for Q and a, if anyone. Yeah.
Next question. First of all, thanks for the presentation, Steve.
Thank you.
I think we learned a lot about the, the different methods that we can deploy to actually protect what is our valuable assets, the information that we have in our databases, no matter what technology it runs on. So other questions from the audience to Dr. Steve mole right now, don't see any, I have one regarding the, the way the system learns about the white listing. I, I, I think I didn't quite get it correctly. So what, what does it actually do? You, you have that sort in a listening mode and then your record, how the application puts valid SQL queries into the database and then you just sign them off as being positive and everything else is blocked.
Yeah. So the, the real challenge here is who has enough time and patience to study the interaction between an application and a database 30 million SQL statements is a lot to look through as even if you are the owner of the database or the owner of the application, you need some intelligent view into what's really going on. So we have this technology in which we call grammatical clustering that takes each of the statements that have been collected during this. We could call it a baselining phase and then extracts one of each type. And quite often the types are many orders of magnitude, fewer than the number of statements we see at which point it is up to the application owner to say what to do next time, that type is seen. Okay. So these are all normal past them through that. One's normal, but I'd like to have a logged record it's in our compliance policy that we have to take a copy of all of the statements that are requesting credit card data, or, but I don't want the card number recorded.
I want that redacted. So we do that. And then all of these other things, oh, I wish we hadn't have seen those before. We're gonna block them in the future. What's nice about this is you put the firewall into the base lining mode and very quickly people see things going to the database that they didn't think ever went there. So we did a POC proof concept in a large American telco into one of their customer systems and DBAs never look at personally identifiable information. Within 20 minutes, we see a DBA issuing select staff from customers in getting all of it back. So it gives very powerful visibility into what's going on and then it makes it very easy to set policy for the future. When the firewalls put into blocking mode,
You were talking about the application owner, making that decision, that application owner usually today, from my perspective, is somebody from business. I have problems reading SQL statements. Sure. Because it's, it's a long time since I had some SQL hands on experience. So there, there is sort of a need for some consultants, some specialists to interpret and, and read aloud to that application manager, what is actually going on? Right?
Sure. And the, the policy owner is normally information security or compliance type officer. They own the, the, the policy, they will need support from the application owner. And sometimes the DBA to say, Hey guys, we've seen this interaction with the credit card table. Is, is this normal? Yeah. So it's, it's not owned by the application
Guy. So you, you could have sort of a hybrid approach where you first ask the application owner, the business guys. So what would you expect as normal behavior? What would people, or what would the application actually look at when, when you do normal business? Right. So you can filter that out. So wonderful. Thanks for presenting that to us, Steve, thanks for coming by to Munich. This concludes our session. Thanks again to Steve. And I'll hand over to the closing keynote.
