Good afternoon, ladies and Tren. This is Martin Kuppinger of Ko a Cole. Welcome to our KuppingerCole webinar, reliable protection for information and databases. The database is Azure central layer of protection. This webinar is supported by Oracle. We will have two speakers today, which is me and which is Roxanne ESCO of Oracle. Before we start some general information on some housekeeping. So, first of all, I probably like to address keeping a call, keeping a call Analyst company. We are focusing on enterprise it, research advisory, service, decision support, and networking for it professionals through our subscription service for our research, through our advisory services and through our events. One of the events and the main event will be held for weeks from today, which is the European identity conference. 2011 co-located was the cloud 2011 conference post conferences to the health May 10th to 13th in Munich, you still can nominate your project@wwidconf.com and then go to the European identity award for European identity award. This is disclosing very soon. Export sponsorship opportunities are available and you can register now to participate in that conference.
So definitely you should have a look at this because it's the conference around IM PRC cloud security related topics, including database security within EMEA, Europe list and Africa regarding the webinars and guidelines, you will be muted central, your muted centrally, so you don't have to mute or mute yourself. We can control these features. We will record the webinar and or webinar recording will be available latest by tomorrow at our website, as well as the presentations of both speakers are available at our website for download as PDF versions, Q a for the webinar will be at the end, but you can ask questions at any time. There's an area questions and you go to webinar control panel, which is usually at the right side of your screen, where you can end the questions. And as I said, usually we pick them at the end. Sometimes we might pick a question during the webinar.
I strongly recommend that you enter questions in the tool once they come to your mind so that we have a comprehensive list of questions at the end of the two presentations and directly can dive into the Q and a session. So having said this, I'd like to move forward to the agenda. The agenda for today is like most cold webinar split to three parts. The first part is the presentation of me. I have a look at, at the topic of database security from general perspective, for some specific coverage of topics like encryption and key management, but really trying to put it into a bigger picture, starting with the term of database governance, where we recently had trend webinar was Oracle on in the second part, then Roxanne upper desk of Oracle will dive deeper into the specific solutions of LAN into the topics of database encryption, key management, talking about best practices and experiences and what tools need to provide in that area.
Part three final, little bit of Q and a is actually where we then will try to answer the questions you enter during the webinar. As I said before, once you have a question, just enter it so that we can directly pick the question down, okay, let's start with my part. As I said, some few weeks ago, we did a webinar on a topic called database governance, database governance, sort of the, the big framework was then we do database security. So database security, if you look at the lower left, then we have database security as one of the technologies we need in the area to support things. And one of the it GRCs or GRC is the acronym for governance, risk management compliance. One of the I here see topics is database governance. So how do we ensure that information and database databases manage and handled?
According to the regulations we have to the rules, we have the policies we have defined and security controls are in place and all the type of stuff. This is again a part of our big chair season. So in fact, we started at lower the upper left edge with our corporate governance. These are the big things for how do we really act in our organization? How do we implement them at the upper right edge, our business processes? How do we deal with our operational risks? And given that most of these things are supported in some way or another by it, we end up with it GRC. So how do we really do our it correctly? And wasn't this database governance topic and database security does technology or set of technologies. We need to implement controls to really protect our information. Given that most of our information has databases.
That is very much about really information security for databases and ensuring that we don't have losses of data. And if you look at all the incidents during the last years, there are so many incidents related to database security issues and thus database governance that we really have to invest in that area. But we have to understand that it's not a, let's say a singular technical topic, but it's something which is very tightly related to a lot of other things we are doing in it. And it governance. And I think it becomes clear as well. If you look at it, very simple picture I have in my next slide. If you look at databases, databases are in fact only one part of our stacks. So we have the applications, business applications, Oracle applications, SAP, whatever. There are tons of applications out there in virtually organization. We have to, to ensure that these applications have access controls.
So they have security built in, we have the database where the data is in. We have the operating systems where we might access the files of the database, where we might access things from that layer. We have to network layer where we transport information. So at the end of the day, we have a lot of layers. And I think it's very obvious even when we are looking at database security, we shouldn't do it in a way where we say, okay, when we have secured our database, everything is secure. It would be as wrong as saying, okay, if we have implemented security at the operating system layer, or if we have implemented security at the application layer for that application, we have secured everything. It's about securing all different layers. And we also could put another layer in between the operating system and the database, which would be, or under the operating system correctly, which would be hypervisor.
So we could say we have even more layers and we have to protect all these layers in an appropriate way. And we have to look at all these layers, but database security definitely is a very important thing because it's a little bit one of the topics which have been ignored by many organizations for quite a while. And if you look at, at many of the reason that instance, as I've said before, many of them are related to weaknesses in the database area. We have to focus as well on all types of use cases. So it's not only data address. So when it's the database or when we create a CSV file or anything out of the database, it's also data and move. So what happens when we move data from the client to the database, from the database back as result to the client, to another database, to a bag system and so on, and how about data and use?
So when we are using data in applications and business analytics, how can we protect them? So at the end, it's pretty broad topic, which means we need a set of different controls. And, and today, as I said, we will mainly focus on, on the areas of encryption key management, but they have to be understood as one element and a bigger story. And I think this becomes pretty clear if we look at technology technology for database governance and for database security, in fact, overall, that's not a single technology, it's a set of technologies. It's about looking at a lot of things. We have features and database management systems. We have database security and we have a broad set of our tools. As I've said before, we will provide the slides for download. So I won't go through every single tool here. What I really want to highlight was this lot of there are a lot of different technologies and within database security, for example, there are encryption key management related things, which are very important, but we have also tools which are dealing with the privileged administrators.
We have the provisioning of users to the database, so that we grant access to an individual user instead of using technical users and all these different things. So it's really about looking at set of technologies. And within these technologies, there are some which are of very high importance to look at encryption. I think it's very obvious. It helps us to, to avoid some things like someone accessing sensitive data from the operating system level and bypassing security at a database itself. So, so the question, however, it was in such a stag is always, what should we protect? So maybe you have an full blown analyzes, a your protection requirements done. That's what, what in German language has a very nice term of should spit off. And a loser. Germans always tend to have very long terms. So identifying which application, which data has to protected in which way, and it would help you to identify where to start security.
You could also do it more, a little bit simpler way and look at your, your protector environments at a very course grain level. Look at your application service you have for system system B CD, look at your databases, you're using your high devices, your operating systems, and so on, then identify, which are the, let's say the specs, which are used for the most critical systems. Then you might end up with, for example, okay, starting when looking at really implementing technology to protect these things, maybe I started with the database because that's what I usually use for, for mission critical applications. Maybe I have to look at my VMware ESX environment because I have virtualized most of these systems. And maybe I look at Oracle web logic because it's my preferred application infrastructure. Then you have to start with, how can you build some layers of protections, which are very consistent and how can you protect everything?
So it's about protecting your database, but it's also about protecting more than your database. And for sure, you always should have a valid concept for security at, at the application level business roles and fine crane access controls and all that type of stuff, where we have probably dozens of webinars talking about entitlement management or authorization management Analyst, things to look at our equipping, a call website when looking down at the role of encryption, which is one very important piece within the big picture of database governance within the big picture, more from a technology perspective of database security, we can look at it at different levels. So we can look at, at the database level, you can look at it at transport level. You might also look at it at the, at the, the hard disk level. So the, this encryption level and other things, I will focus in that case on database level and transport level.
So encryption database level, it's about user encrypting, the entire database, which is protecting it against attacks from other layers mainly. So the rate of the operating system, being able to trust, copy a database file, take it offline, analyze it all the time in needs. That's something very better can protect by encryption. For sure. If someone really has all the time, all the, say that the power to analyze things, it might be that also encryption reaches it limits at some point of time. This is also very interesting, I think for cloud based in sense of databases, because yeah, that's, that's something where you have data, let's say much less under control than you have your internal data centers. However, you shouldn't overestimate security of your on-premise installations. Encryption database level also can be done sometimes at specific columns or protect specific sensitive information like specific personal ally, identifiable information, other things you have the encryption on the other hand at the transfer level.
So protect information when it leaves or enters the database, how do you protect communication channels? How do you protect the transactions? So encryption is a, a multifaceted thing to, to look at, and it's not the right encryption. It's about combining the things you need in encryption. What the obvious challenges affect encryption. One challenge always is performance. So if you encrypt and decrypt something, it's, it means it's obviously a little or much depending on the implementation, slower than working without encryption. So you, you never can be as fast, but you can be close to as fast as was our encryption, but there are some very obvious limitations. So you have to, to keep this in mind, when, when looking at encryption on the other hand, we all know that that a lot of things we, we are doing with encryption, we, we don't feed them anymore.
So if you look at the accessing websites, we HTPs, yeah. We don't really have an impact there with databases and high volume protection that might change. And these are things to keep in mind. We can't really process encrypted information. There are other approaches to do this. So if you need in a test environment, we might just mask data. There are other technologies to do that, which aren't the topic of, which are a part of database security and database governance. And we have the topic of key management. So encryption always needs keys and keys have to be managed. And the bad thing with a lot of solutions we have out there is that they don't re let's say don't handle the keys in an appropriate way. And when the key isn't secure, you definitely have an issue. So it's really about securing the keys and handling them appropriate.
Otherwise, the value of encryption is done is gone. Okay. Aspect of key management, one of my last two slots, as I said, encryptions based on keys and encryptions only as good as keys are secured, which means sometimes you might rely on, on specific hardware are things. And also the manageability of encryption heavily depends on the key management. So how do you deal with the keys? How do you distribute keys in other things? And in many cases you end up with, let's say some sort of insecure solutions. You need to define your not only your technology for key management, but you also need to define processes, organizational responsibilities, how to really handle the keys and to keep security high.
And I think the one thing you really can't do wrong is trying to save too much money when it comes to key management, that's definitely the wrong place. So investing an encryption without looking at a part of key management, the wrong approach to do it, you really have to understand that part of good encryption. So, and that comes at a price. You can't save too much money here. So where to start when, when we look at all these things, when we look at the, the entire topic, my perspective is you first should have a sort of a holistic concept, which means not an OS security only, or application security only, or database security, only concept. You should look at it at an, how can I secure my information across the stack and database security is a very, very, very important element within that. And it's is one which is still too frequently ignored or not implemented.
Sometimes I think that ignore part is strange. It's more about we haven't done it yet, but it's a very important thing encryption done, right? Helps you in protecting against text from other layers. And that is a very important element. It comes on price, but it's a very important element in data security concept. And what you really should do is you should design your, your holistic concept in the context of protection requirements. So where do you really need a strong protection? Where do you need, what type of protection, where to start that are the questions you should ask yourself, then you should decide about technologies. And within these technologies, database security has a very important place. And talking about database security there, specifically about database encryption, key management and related things. That's what Roxana do will do right now. So I will hand over to Roanne make her presenter. Roanne that's your part.
Thank you, Martin. Let me just get everybody here. Can everyone see my screen? Hopefully. Great. Yes. So wonderful. Thank you so much, Martin. So I'm kin, as Martin mentioned, I'm responsible for database security, product marketing here at Oracle. And today we're gonna look at Oracle advanced security, which is a complete database encryption solution from Oracle. And I'm just gonna recap a little bit, like why, you know, for why are we talking about database security, right? Why has things like, you know, why is database governance more important than, you know, it's ever been before? Well, in most organizations, two thirds of sensitive and regulated data resides in their databases, right? So this is all of our PII type of information. This is email address. Customer transaction is more and more business processes become online, you know, become, become automated through webinar interfaces and things like that.
All of that data ends up in, in databases. And we see that the amount of that data and database that is doubling nearly. So all of our sensitive information in an organization typically tends to be in our databases. So how we manage that data, how we protect that data is really critical. Unfortunately, we don't seem to be doing a very good job of it, right? We've got over 900 million breach records, according to the Verizon 2010 data breach investigations report. Most of which ended up out of database servers. Again, that's not really a surprising number because where else was data, you know, originate from, it would originate from database servers, but we're seeing so much of this data basically being breached from compromised database servers. So we're not gonna talk about all of the different ways in which database in which database servers can be compromised.
Today. We are gonna focus on a few key areas of vulnerability that we saw from our I G independent Oracle user group survey. The Oracle sponsors every year. So what we saw is that 29%, so almost 30% do not have a mechanism of preventing OS access to sensitive data stored in database files. So what that means is that if somebody has access at the operating system level, whether that's a system administrator or whether that's a hacker that's managed to get, as far as your, you know, as your operating system, right? If the files that the database is using to store data in arm encrypted, they can basically open those database files and any kind of editor and see the data essentially can declare text. So it's very easy for somebody to be able to see database data stored and files. If those files are not encrypted, the next one is network encryption.
We asked a question, are you uniformly encrypting database traffic? And what we found is that less than a quarter are actually preventing somebody from being able to each drop to their network traffic and see again, clear text data, moving over the network to the database, 16% of organizations aren't backing up, aren't encrypting backups for exports. So we do a sensitive database export, right? Let's say, from moving, you know, for sharing with a partner, from moving into a data warehouse, or we do a backup, right? I mean, how many times have we all heard the story about the lost backup tape or the lost backup? Right. So less than despite that back only 16% of organizations are actually encrypting their backups and exports. So we're still seeing quite a lot of data, which is either accessible the network over the OS backups, right? Lots of third tech data just kind of floating out there, despite all the regulations, both in the United States, north America, in, in Europe as well around privacy.
You know, that specifically call for encryptions. So for example, TCI, some of the European privacy laws, specifically calling for encryption, we still don't see that happening. So what Oracle advanced security does is to protect data from unauthorized database users. If you really think about it, anytime we're not encrypting data, we're allowing somebody who has no access to the database itself to be able to see that data to somebody who's listening in on, on the network, right? Who's not a database client, not a database server can see that data, anybody who is, you know, has OS access. So essentially what encryption does is it prevents database bypass. It prevents somebody from being able to, who's not a database user from being able to see data as it's either on media, over the network or rest by encrypting data. The database layers will talk about minute. We don't need to do any application changes, right? So the applications don't have to encrypt your decrypt data. The encryption happens within the database layer and with Oracle security, we also include builtin key management. And we'll talk about all of these areas, detail and it's database. You have high performance and it makes it very easy.
The thing we're about is what's called data encryption for columns. So this allows us to do data rest encryption at the column level. And the main thing to take away here is this is literally the screen that you would use to encrypt data within the database. All you would do is you would select the column that you wanna encrypt the encryption algorithm and you hit the apply button. And that's literally as, as easier as it's, it's literally a point and click to encrypt any column you want within your database. It supports all column types, including Oracle database, 11 G secure files, which is essentially a way that you can store unstructured data in the database, as well as structured data. And the data is cashed encrypted within the SGA. So within memory structure, the data is actually encrypted as well. It it's decrypted only when you do reference it and it's encrypted every time you modify it, right?
So essentially within memory gets, it gets encrypted and encrypted whenever you need it to be. And the undo and redo logs that are generated are also encrypted. And this is another important thing that you have to consider is your database leaves a lot of logs, right? You've got a lot of redo logs, undo logs, audit trails, and things like that. And you wanna make sure that the data it's encrypted in all of those places where it's written. So with advanced security, for what I data encryption for columns, to make sure that they encrypt that the data stays encrypted in all of those different mode. Whenever it's written out from the database, indexing is supported, but what's important here is because the data is encrypted in what's called the SGA. The index itself is encrypted. So what that means is that the data can't be stored to certain kind of column operations inherently, aren't gonna work.
So for example, a range scan, right? Because the index is encrypted. You can't support a range scan with column level encryption and the encryption keys are table specific. So what that means is that if you have a, a quarantine constraint within your schema, right, which means that basically you say that this particular field and this table is gonna also be a key to another table because they're encrypted with different keys, right? The keys are table our table specific, but we end up with, we lose that foreign key constraint, but that's okay. I mean, there's many applications where that isn't really an issue. So for example, social security numbers, we tend to not use as keys anymore. So that's a perfect example for something I may wanna use column level encryption, and these kind of constraints would matter to me. However, you know, there are applications where that kind of thing doesn't work.
So we also have transparent data encryption for table spaces. So what that means, again, here's a screen basically for how you would do this. You select, when you create your table space, we say that it's encrypted. We select, you know, the algorithm that we wanna use for the encryption, this get 92 and that's it. So this is literally what it takes to do an encrypted table space. And when we encrypt the table space, one immediate benefit that comes out of it is that we don't need to specify specific columns for encryption, right? And this is very important when dealing with let's say, legacy applications or third party applications that can have quite complex SEMA, right? So if you're purchasing an application from a vendor, you may not know exactly what columns contain sensitive information, right? So by setting up that application in a trans in a, in an encrypted table space, you don't need to know the columns.
All of the data, whenever it's written, you know, out to disc will be encrypted. Whenever it's read out from the disc, it's gonna be decrypted. And because it's going to be sent to, to the application, essentially that's an authorized authenticated database user. They're gonna get that data in the clear, right? So the application never even knew that the data was encrypted. The data with tr with table space encryption is actually encrypted at the block level. So it's written out to dis as, as a block encrypted and it's decrypted block is decrypted when it's read back in now, because essentially what that's telling us is that the data is happening. Encryption and decryption operations are happening lower within the database kernel. So by the time the data gets into our SGA, it's actually unencrypted. So what that means is that our index now's gonna have clear text.
So there's no limitations. All of the limitations we had before. So you range scans or, you know, foreign keys. All of those are, are removed because essentially the, the data is it's decrypted lower in the, in the Oracle kernel, as it moves up and sort of, we need to have access to all of these things. Now, the undo and the redo laws are still generated encrypted. Cause again, we wanna make sure that time we write out our data's gonna be encrypted, right? It's not just within the database files. We wanna make sure that the laws are encrypted as well.
Now, the other thing with transparent data encryption, as Martin mentioned earlier, key management is the most important aspect of encryption, right? So with advanced security, it includes built in key management. So transparent data encryption allows us to generate store and rotate keys. And you can see some examples over on the slide over to the right, very simple to do so, essentially all we, we can create, we can create a wallet, we can generate our master key. Do we open the wallet? A simple command allows us to rotate it. And we use note here is that we use a two tier key management architecture. So what that means is that we have a certain set of keys that are used for encrypting tables, columns, and tables, or encrypting the table space, right? So we have the data specific encryption keys, and then those keys are actually stored in the database for performance reason, but they're encrypted, right?
And they're encrypted with something called the master key. And the master key is stored outside the database in an external security module. So we've got the data encryption keys that are used to encrypt columns table, you know, table spaces within the database encrypted with the master key, that's stored outside the database. And that external security module can be on Oracle wallet, which is a PKCS 12 file. So there's a few who are familiar with that, and it can also be a hardware security module that can meet folks in common criteria requirements. And basically we interfaced using PKCS 11 APIs to these hardware security modules. So we we're constantly certifying with new ones. We've already certified with most of the leading HSMs that are on the market today. And as new ones come, you know, as new ones come on board, it's very easy for us to integrate those in, because again, it's an open API there, there's also separation of duties, right? Very important when we're talking about government and because the wall password is separate from the system or DBA password, essentially that master key can be managed by a different group. It doesn't have to be managed by your DBAs. It can be managed by a security group, for example, and, and can unlock the database for encryption and that kinda thing. But again, any authenticated and authorized database user can basically get access to clear text data.
Now, one thing that comes up a lot with performance was trans with encryption is performance, right? So I wanted to talk a little bit about what is transparent dating for performance look like well that, you know, there's a lot of myth out there that, you know, encrypting data is expensive and that myth actually started because of third party solutions, right? It's very, you know, you're trying to encrypt data, you know, and you're not doing it in the database kernel, right. Essentially you've gotta have all kind of views and triggers and things like that, which actually can, can cause a lot of overhead. But given that we're doing the encryption within the Oracle database kernel itself, right? So we're encrypting data automatically as it's read and written out incremental use is gonna be less than 5% in those cases. Now on top of that, if you're using cryptographic hardware.
So for example, the westerner chip, right, or we show some of the results here, you're gonna have a 10 X feed up. So if you think about it, you're talking about 5%, you know, overhead on average with a 10 X speed up, if you running on cryptographic hardware. So if your processor has board crypto acceleration like the Westmere processors, you know, or the Zion processors, right, you'll see that performance increase automatically. And the incremental CPU can be, can be reduced even more if using, if you're using Oracle advanced compression. Right. And the reason that's important is once we encrypt something, we really can't compress it. Right. Encryption basically randomizes the data, which means that we can't compress it once it's been encrypted. So it's very important that we do compression and encryption in the right order. We wanna always compress our data before we encrypt it.
Right. So if you're using Oracle advanced compression, right, let's say your compression ratio is 75%, which is pretty, you know, pretty actually conservative. Right. So that would mean that we actually have to encrypt 75% less data. So again, you're getting a lot of performance. You're getting a lot of performance improvement as well. If you're using compression encryption together. Now what about using, you know, using TDE within applications, right? So I showed you how easy it is to set up transparent data encryption using, you know, using the buoy, right? Using the web interface where you can just point and click and select, you know, a few, a few fields and specify your algorithm. And you can do that if you're writing an application, or if you're writing a script, you can do the same thing command line. So for example, there's a very simple SQL command that you can type in to modify, you know, to modify encrypting a column.
All we have to do is say an altered table, specify, you know, specify the card that we wanna encrypt and that's it. So if we wanted to encrypt a column in the new table, we would just basically add, you know, how we wanna encrypt it within, within the definition of that table. Same thing with a table space that what's important is we can only encrypt new table spaces. We can't encrypt existing table spaces. And so if we do wanna do that, and there's ways we can do, we can set up an encrypted table space and we can either move the data over sort of as a one time only operation or there's ways that you can do it. If some of our customers have without any kind of downtime using other features like partitioning and read depth. And we'll talk a little bit about that as well, but it's very easy to integrate transparent data encryption into your existing as you're writing your applications, or as you're writing your script to set that up.
And there's also support for numerous Oracle and non-oral applications as well. We've certified with Oracle eBusiness, suite people, stock cable SAP, DD Edwards retack and, and, and many other applications as well. Because again, very straightforward really is transparent, right? You set up the table space, you set up your, you install your application into that table space and that's it. And then as part of certification, we also provide you with the migration script so that if you've already got, you know, if you've already got like the e-business suite running right in the non encrypted table space, and you wanna move over to an encrypted table space as part of your 11 migration, then we provide you with the script and the notes necessary to do that migration. So that's really what we mean by certification, because it really is transparent, but you do want, you know, those scripts and everything to basically make the migration as easy as possible.
The next thing we're gonna talk about is another component of advanced security that allows us to improve database traffic. So we wanna be able to improve traffic over the network to prevent men in the middle attacks, right? So we wanna prevent somebody from being able to SROP on our, on our connections between our, between our application servers, with a real database client and the database servers. And we can do that using standard algorithms like AEs, RSA does triple does, right? And we also have capabilities for check sums in there, right? To essentially insured data integrity and prevent modification on transactions or replays, right. We don't want somebody to essentially be able to send the same transaction over and over again, with that deposit to a bank account, right. We don't want them to be able to replay that missing packets. And we use empty five and SHA one for that. There's also no infrastructure changes, right. And that's important too. So again, the same way that we have pointing for transparent data encryption, for data reps, we can set up encryption between database clients and database servers, same thing, point and click. And there's no infrastructure required. I don't have to have VPN boxes. I don't need to, you know, change configuration on my routers. None of that's required essentially just point and click on either end.
Now we talked about, you know, earlier how many customers are really, you know, Oracle users are really not encrypting their media, right? So they're not encrypting, you know, their exports and their backups, right? Transparent data encryption is automatically integrated with Oracle data pump, which allows us to do both export and import to OS plot files. And this is very important because this is the way that a lot of organizations move their data from their production databases to their data warehouses. Right? So we do, you know, we do an export of our data. We generate a, and then we import that into our data warehouse. We don't want that data to be in the clear, right. We wanna be able to encrypt that the same thing with, you know, with backups. So TD is also integrated with Oracle RMAN, which is our backup utility to allow us to encrypt our database backups and automatically do the key management for recovery, right?
Both RMAN and database and data pump, do the compression and the encryption in the right order. What I mentioned earlier, obviously when we're talking about backups and exports, we wanna always be able to compress this, right. And we wanna be able to compress and then do the encryption. So those by using these, I think by using these tools have already been integrated with T you can get that capability versus if you were using some other type of tool that didn't, you know, that wasn't integrated with TDE, you'd be dealing with encrypted data and therefore you wouldn't be able to compress it. Now you have a couple of options when you're encrypting data for backups and ask for it. You can either encrypt it with a master key, which is good, but then you have to have the master key, obviously on the other end. So if I was talking about, as I mentioned earlier, let's say, this is our mechanism for moving things into our data warehouse.
Maybe we want, we don't wanna have our master key living in our data warehousing environment. So what we can do is we can actually encrypt with a pass phrase as well. So I can do an export of data. And instead of encrypting it with a master key, I can encrypt it with a pass phrase that I can basically communicate in a, through another channel. Right. So essentially I wouldn't put it together, right? I wouldn't give you, here's the, you know, here's the, here's the encrypted export, by the way, here's the pass phrase. So that would be communicated off channel, right? And that one, we don't have to distribute the production master team with every export or every backup. We can use a pathway phrase for those. And the master key important point is not automatically backed up with the database. So again, for security reasons, we don't wanna have the key along with the data, right?
So it's not gonna be automatically backed up, but it's very important that you look at how you manage your ma your master key backup, because you really don't wanna lose that master key. If you lose that master key, your kind of screwed, you have to be able to back that up separately and make sure that you're managing that properly. The last feature of Oracle advanced security that we're gonna mention today is strong authentication. So again, the reason we do encryption right, is to prevent people from bypassing the database, right. We wanna make sure that they can't look at files at the operating system level, that they can't use drop on the network, right? So, or that they can't look at backup the next force, right? We wanna make sure that the database security controls aren't bypass. So the other thing we really wanna do is increase the assurance of database users.
And the way we do that is with strong authentication. So TBE is always going to return clear text data to authenticated authorized database users, right? This is why transparent. So the encryption happens automatically when the data, you know, written out to this, it happens, the decryption happens automatically when it's read from the disc and assuming that the user is authenticated and authorized, which is why we're performing that, that read, for example, in the first place, right? The data's gonna go back and clear to the user. So it's very important to basically increase the assurance of our database users to protect against stolen credentials. Right. You know, we hear all the time about, you know, email addresses, things like that, being stolen, Sping tax. So we wanna make sure that database users are who they say they are, especially privileged application users and DBAs. So with, with a strong authentication component of Oracle advanced security, we can, we can change the way that people authenticate to the database and just straight, you know, ID and password Tolbert to PKI essentially X 5 0 93 search.
Or we can just plug in end authentication mechanism through support for the radius protocol. So if you are using one time password tokens or risk based authentication, all through radius, as an interface, you can plug in those other kinds of security control of authentications so that you can basically, you know, be sure that you'll, you know, DBAs who they say they are, for example. So the last thing I'm gonna mention is the case study. So one of our customers TransUnion interactive who's if you're not familiar with TransUnion, they're a global leader in credit information management. They're the folks that do the credits scoring on credit history. I'm close. I'm actually close to a bill, you know, to half a billion users worldwide. Right. And they have to comply with PCI DFS, which requires, you know, requirements for data resting friction. And they're running the custom application.
In fact, they're running many custom applications and they use a, a log, right. What's called a large object data type, right? So essentially they're using the database to store a data structure from their application and they wanted to have that encrypted. Now they couldn't really, you know, they encrypted at the application layer, right. They would have to change all the applications, which was, which would've been very painful for them to do. Additionally, they wouldn't be able to take advantage of things like compression, things like indexing that the database does, right. Because all of that data, they were encrypting of the application layer. Would've been opaque to the database, so that wouldn't have worked for them. They also looked at things like tokenization, right. But that would've required them to change again, all of their applications or dis encryption, which wasn't really gonna provide the, the security that they needed.
Right. What they're trying to prevent was essentially having somebody with OS level access, being able to see that data. But with dis encryption people with OS level access can see data at the operating system level so that wasn't gonna meet the requirements. Plus there's gonna be a very expensive solution because they'd have to upgrade all of their storage, right. Not a cheap proposition. And so basically they selected Oracle advanced security with transparent data encryption and they required zero application changes. Right? All they really had to do was turn on table space encryption. They went with table facing correction. They did this as part of their 11 G migration. And they also had zero time. Right. Even though they had an existing table space, they had a requirement for zero account downtime. So what they did is they basically deployed immune corporate table space and they migrated data over using partitioning and red death.
Right. They moved over from their, from their unencrypted table space to their encrypted table space without any kind of D time. Now, another key thing for them was, again, the key rotation did not require any downtime or impact performing, right? So because we have this two tier key architecture system, when you rotate your keys, we don't have to decrypt, let's say, terabytes of data, you dealing with a terabyte database, you don't have to decrypt. And re-encrypt all that data when you're rotating your keys, all we're doing is essentially decrypting and re-encrypt the actual data keys themselves, right? Because we have that two tier key management system and it works seamlessly with all of the other Oracle database features that they wanted to take advantage of like partitioning and compression and pretty much satisfied all of their auditor requirements around PCI. We have some other case studies we're not gonna get through today, but I'm gonna mention, you know, how you can get to those.
So at the end of the day, really database encryption is part of a complete defense in depth strategy. We talked about all of the other solutions, sort of at an overview level on the left webcast, which is why we kind of down on advance security today. But if you missed that last webcast on database governance, I definitely urge Richard to go back and take a look at that. And these are all of the solutions that Oracle offers as part of a complete defense in depth strategy, right? Encryption is one is one part of the solution and it prevents database bypass. But we also wanna look at solutions like database models and label security, which allow us to have access control within the database and prevent even privileged users from being able to access data. We wanna look at solutions like audit falls until we call that track changes and auditing on, on data in real time, our latest database firewall, which we'll hear more about in an upcoming web cap, and also just protecting your production and non-production environment through configuration management and Oracle data masking. So you can find out more about all of these solutions on oracle.com/database/security. You find out more about advanced security, that's the URL go to database slash advanced security. And also if you wanna see and hear about more customer stories, for example, to have a podcast with Ken union, where they talk about their experiences, you could go to Oracle, do com go to database security customers. So with that, I think we'll wrap it up and have time for Q and a.
Yes, thank you, Alexei. And so, as I said before, right now we will start our Q and a session. And it's latest time to enter your questions, using the questions to, in the go to webinar control plan, which you will find as the right side of your screen, so that we can go through your questions. You have around database governance, database security, database encryption, key management, particularly. So just start entering your, your questions now. So I I'd like to, to start with one question, which is, I think a very, very important and the whole sort of general one, which is around when looking at the different approaches and you you've touched it a little bit during one of your last slides. Why is from your perspective, disc management, not sufficient?
Well, the issue with disc encryption Martin is in terms of access control and what threat are we trying to prevent? Disc encryption is useful from the perspective of, you know, essentially disre retiring, right? So if the data's encrypted on the disc, when I basically take that disc, take it out of the machine and do whatever with it, the data's gonna be encrypted. So it can't fall into the wrong hands at the disc level. Right. But with disc level, with disc level encryption, any authenticated authorized disc user versus any authorized authenticated database user. So any authenticated and authorized this user is gonna be able to access data that's stored on that disc. So in the case of our, of our database, right, what we're trying to prevent is somebody who has operating system level access, right? So for example, an administrator, especially for hosting, right? So maybe we're in a cloud environment where we're hosting our database, right?
So other people are managing and have access to the operating system, but they're not really authenticated. They're not really database users, right? So they shouldn't be able to see the data that's stored in the database. They're really just meant to be able to see, you know, things of the, at do layer, if with dis encryption, they would be an authenticated and authorized user. So they could open up a file and an editor and see that data and clear text. They could potentially copy that file. Right? That's another, that would be another operation that can perform. They can then take that file. That file would be decrypted. They could put it on an unencrypted file system. And again, they could see that, you know, or not encrypted this. And again, they'd be able to access that data. So it's not really preventing the threat that we're trying to prevent against, which is somebody bypassing the database.
Okay. The next question is what is the best encryption strategy for a large and often used database?
So for large databases, I mean, it's the same, it's the same, right? You really want to use transparent data encryption. If you're dealing with a large database block, encryption is gonna be more efficient. So you're really gonna wanna look at table space encryption. So you're gonna wanna be able to encrypt and crisp block that your written read out to IO, which pretty much once you're talking about having, you know, especially if you're running on hardware that has cryptographic acceleration, you're gonna see almost no impact from that encryption and encryption operation at the block level, it's gonna be pretty close to zero. So when you're dealing with large databases, you're really, you know, block encryption is gonna be, you know, your best bet with table space encryption. And again, what's gonna be really unique about our solution is gonna be that key rotation, right? As Martin put it, you know, key management is the hardest part of, of any kind of solution. And because we have that two tier key management solution that will really come, come in handy because you're not have to and rein all of your data. If you're with large database, every time you have to.
Okay. Another question we have here is mentioned, TDE is integrated with Ironman. That's that mean I have, if I have TDE enabled my Oracle RMAN backups automatically encrypted, if so, how do I do I restore it offsite?
So you have the choice. So it is integrated, but you have the choice of doing encrypted and non encrypted backups, but obviously you would want to do an encrypted backup. And all you really have to do is just make sure that whatever way you're using. So for example, let's say that you're encrypting your RMAN backup using your master key. You just wanna make sure that your master key is gonna be available. Let's say, for example, in your disaster recovery environment, where you're planning on restoring that data. Alternatively, as I mentioned, you can encrypt your RMAN backup using a pass phrase. So essentially rather than using the master key, you can just use an encrypted backup with a pass phrase. And then on the other end, you can just encrypted by entering in the appropriate pass rate. And then you would basically, and then you import database separates master one in your production environment. One environment, you, your
Questions, questions, please enter them now while I'll pick the next question we have here. So question is, is Oracle database the most secured database available? So I think I know the answer Alexei will provide,
Do you want me to answer that? I obviously we provide, I mean, you know, objectively speaking, right, the Oracle database has more security features than any other database on the market. And part of that is if you think about it, we started out actually in the secure, you know, secure database business. Our first customer over 30 some years ago were several government agencies dealing with highly sensitive information that needed to manage that information. And for a long time, they drove our security roadmap, right? So for example, transparent data encryption has been around for many years and has only recent even introduced by other database vendors. Some of which don't even do it natively some of which actually OEM third party solutions. So Oracle is really the first database, for example, to provide transparent data encryption, same thing with, you know, know, label security privilege, user access data masking in place within the database itself, right? Those are all features that today are only available within the Oracle database.
Maybe, maybe I ask something from my mind you Analyst perspective and, and I think without rating the, the, the, the specific elements where you have a competition, I think it's very, very clear that Oracle has the broadest portfolio of database security solutions of any vendor that market at that part of time. So I think that's definitely a strengths of Oracle that they have a very broad portfolio of different tools ranging from some solutions which can be used in Netchi environment like database firewall and others to very specific solutions, to secure different aspects within an environment. And I think that's definitely a situation where, and a fact we have out there. So from the, the breadth of offerings, Oracle definitely has the broadest portfolio.
Okay. Any other questions from the audience? If there are no first questions? I think we have a very interesting webinar today talking about database security and specific about specifically about database encryption and related topics of key management and strong authentication. And I think the presentation for made pretty well clear that this is a topic which requires a very strong and then well, so solution. And then what I try to, to deliver to you was that overall it's a part of a big picture. So it's encryption is very important thing, but you have to understand role plays within the bigger picture of database security. Okay. We have trust out question. So I'll pick this question before we end. What happens when you lose your master key after encryption? So my answer on that is definitely you obviously then I had a problem with your organizational processes and the related things, however, yes. What happens if works?
So what happens if you lose your master key
After encryption?
Well, you know, really your data would be lost. I mean, so there are HSM devices which offer things like K growth, right? So for example, if that's an, if that's a concern, right? I mean, we, we are customers to take good care of their master key because really there is no back door, right? So if you lose your master key, you've lost your master key and you can't recover your data. So you wanna make sure that you take good steps and have, you know, the proper operating, you know, procedures in place to protect that master fee. And then you can also, as I mentioned earlier, you can store your master key in different kinds of external security modules. So one of them was the Oracle wallow to the Ts 12 file, but you can actually also store it on an HSM device, a hardware security module, and many hardware security module provide key escrow. So for example, what's called, you know, NM secret splitting, right? So that basically the, the master piece of protect could be essentially recovered by two or three people within your organization coming together, providing other pieces of that. So there are KIOS for capabilities available in HSM devices that, you know, for, for organizations that are really concerned about that, you know, that's another way that you go.
Okay. So I think that's the answer to this question, as I said again, thank you to all the attendants for attending this call webinar and thank you to Alexei for doing that presentation within the webinar. Last question I can pick very shortly HSM module is a hardware security modules, something which provides key storage and encryption capabilities by hardware design, which which came at in Richard point of time. As I said, thank you again for participating today in this webinar, the podcast and the presentations will be available by tomorrow at the call website and those miss European identity conference. Thank you.
Thank you.
