Database Security: Part 1

Join hosts Lois Houston and Nikita Abraham, along with Senior Principal Database & Security Instructor Ron Soltani, as they dive into the critical topic of database security. In the first of a two-part series on database security in Oracle Database 23ai, they discuss the importance of protecting data against external and internal threats, common security risks like phishing and SQL injection, and the principle of least privilege.   Oracle MyLearn: https://mylearn.oracle.com/ou/course/oracle-database-23ai-new-features-for-administrators/137192/207062   Oracle University Learning Community: https://education.oracle.com/ou-community   LinkedIn: https://www.linkedin.com/showcase/oracle-university/   X: https://twitter.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, and the OU Studio Team for helping us create this episode.   --------------------------------------------------------   Episode Transcript:   00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative  podcasts, we’ll bring you foundational training on the most popular Oracle technologies. Let’s get started! 00:26 Nikita: Hello and welcome to the Oracle University Podcast. I’m Nikita Abraham, Principal Technical Editor with Oracle University, and joining me is Lois Houston, Director of Innovation Programs. Lois: Hi there! In case you missed last week’s episode, we’ve begun a new season of the podcast, talking about all the new features in Oracle Database 23ai. We covered blockchain tables and new features, and today’s episode is going to be one of two that will be dedicated to database security. Nikita: Right, Lois. So, in Part 1, we want to set the scene, so to speak, by looking at an overview of database security so that when we discuss some of the new features, we’ll know exactly where they actually fit into the process. Joining us for these two episodes is Ron Soltani. Ron is a Senior Principal Database & Security Instructor with Oracle University.  01:16 Lois: Hi Ron! Thanks for being with us today. To start off, let's discuss the importance of database security. Why is database security so critical today? Ron: Security requirements, describes the need for keeping things private and make sure that we protect against threat, against data destruction. We also have, today, data that is global. Therefore, there is consolidation of the data. There is globalization.  There is data sourcing, locational, where the data is actually located, rules opposed by different governments, and guidelines that enforce a certain type of security administration on the data. And finally, there are many different companies or organizations that actually come up with either guidelines or rules that must be followed for security aspect that we must set up and build compliance.  02:24 Nikita: Ron, what are some of the common security risks that databases face?  Ron: Security risk can include external threats that could be unauthorized users trying to use phishing, get privileged user information, and get in as a privileged user to do whatever damage they want. Denial-of-service attack, one of the most common attacks out there where the attackers just create or attack the components, like a listener, for example, in a database, and cause a situation where the listener can no longer establish connection to the database. So now no client can connect to the database to get data, which is that denial-of-service attacks.  Having unauthorized access to the data-- so again, this is generally done through phishing or sometimes even SQL injection. SQL injection also allows you to insert SQL statement in the application where it's not expected, where it can then convert into an executable in the database and then have unwanted data returned for the user.  03:42 Nikita: Sorry, can you explain that? Ron: For example, when you go to Google, you want to run a search. They expect you to say, meaning of a particular word.  Now, what if I knew the structure of the data organization in Google? And instead of just putting in meaning of whatever word, I actually plug in a SQL statement that then passed along to the Google system to be executed. And then that SQL, if the components and everything exist and within the privileges of what is being executed, could expose some information to me. So that's the idea with being able to perform that type of operation.  04:24 Lois: Ok. So, those are external threats. But, could you also have internal threats? Ron: Internal threat could be abused by someone who is privileged, could be sabotage of the system and the data. It could be data complexity that creates an environment where data is not properly being secured and even accidental damage. It's a security issue.  And then finally, if there is a damage, we do need to be able to perform recovery. So we create backups and data access in those. Therefore, those recovery information must be properly secured. And finally, the omission, being able to block access or cause issues with the data. Then having external threats coming in through the internal abuse, so internal abuse could actually open door to allow external threats to get in.  Now, the final type of security risk could be coming in from partners who have privilege to be able to load or access and get data. For example, I may sell a particular product. But the product description is actually coming from the product distributor.  05:47 Nikita: Yeah, so they have access to push that product information into your system. So, what are the typical points of attack for a database? I’m familiar with phishing. Ron: People send you emails or do something to be able to get information from the pieces and things that come back. For example, this is one of the reason for many operation. We would return false error messages. Like in Oracle database, if you don't have privilege on the table and you try to select it, we tell you a table or a view does not exist. So this way, you don't know if it's a table, you don't know if it's a view. And as far as you know, it doesn't exist. So the name you have does not correspond to any particular data.  06:32 Nikita: That’s clever! Ron: If we would tell you don't have privilege, now you know the name of this table exists. So now I just got to find a way of hacking the table. So this is basically phishing means, extracting different pieces of information through different channels, being able to put them together.  Then in database, we have some privilege known accounts that if not protected can be a vulnerable access. The back doors into the database. For example, somebody being able to get to the operating system DBA group, and then connect to the database without user ID and password.  That's why we have to protect every layer. Any debug codes that may be available that could reference how the operation of the system is actually going. Creating cross-scripting between the different data and then operations that goes on. And as we talked about, SQL injection.  07:28 Lois: Can you dive a little deeper into SQL injection, Ron? Ron: With SQL injection, you kind of have to understand that, in general, SQL injection means somebody, like we said, knows the structure of something, knows the structure of the way the application is operating, and then be able to inject a SQL statement where they would generally put a condition or pass some parameters or some information to the application.  So, then that SQL statement becomes part of that statement and submitted to the database. Now, we need to understand SQL injection is not about the person, is not about generally your overall configuration of the database.  The most important aspect of SQL injection is about the session that is actually doing the work. For example, if I am a DBA and I am going to collect statistics for a table. If I connect a SYS DBA to collect that statistics and somebody hacks into my session and inject a SQL drop database. Database gone, because the session has SYS DBA privilege.  But if I have a user that only has create session privilege and execute a script. And in this script, I write the statement to collect statistics and I give that script only the privilege to collect stats. So now I can connect as that user with that minimal privilege, just execute the script.  So now anyone inject any SQL into the session, that will never be executed because the session has no privilege. So this is the important of SQL injection for us to understand that the importance is what happens at the session level.  And many of the security element we will see, like read-only session, hybrid read-only PDB and things like that are related into this type of SQL injection or abuse.  09:30 Lois: Yeah, we are looking forward to talking through those new features in the next episode. Ron: So the common vulnerabilities can be exploited, and also any of the users that are part of the operations that can be set up into the string and supplied into middle of statements and things like that.  09:56 Did you know that Oracle University offers free courses on Oracle Cloud Infrastructure? You’ll find training on everything from cloud computing, database, and security, artificial intelligence and machine learning, all free to subscribers. So, what are you waiting for? Pick a topic, leverage the Oracle University Learning Community to ask questions, and then sit for your certification. Visit www.mylearn.oracle.com to get started. 10:25 Nikita: Welcome back! One of the concepts I wanted to ask you about, Ron, is the principle of least privilege. Can you explain what it really means? Ron: Principles of least privilege, again, means the work that needs to be done has to have minimal privilege.  10:40 Nikita: But, we’ve always thought about that, right? Giving a user minimal privileges… Ron: Well, back in the old days, we used to execute everything as a schema owner.  Therefore, we had privilege on all the data. Then we said, OK, let's create schema users and only give them like a read privilege or this privilege. So they can only do the type of work they need to do, which is fine.  But at the same time, that can be very complex. Now I need a lot of different users and whatnot. So when it comes to principles of least privilege, this is generally about only installing whatever software that is required. Only enable or turn on whatever machines and segments that is going to be used.  Have proper operating system level users and privileges configured for all of the software that is installed at the operating system level. Have proper administrator account that are properly maintained. Set up privilege user account for each operation.  So when we do maintenance and database administration, we are not creating very high-level privileged session. That's why some of the differences privileges was created in database 12 and up, like Sys backup, Sys DG, Sys RAC. So you don't inherit the privilege as Sys DBA to actually do the work. You only have privileges for what you need.  And, of course, limit the user's access to particular object and things that they need to do. However, as I mentioned, this is not just about the user level. This is also about the session level. If I'm going to do maintenance and I'm connecting as a schema owner, somebody inject a SQL drop table, table gone. So that's why it is very important for us to be able to have control over how sessions can also operate within the database.  12:34 Lois: Right, so, what about the strategy of defense in depth? Ron: Defense in depth. That means we have to strengthen and apply security at every level, whether it being at the securities applied at the operating system in the database, in the application, in the network.  So we have to have policies defining all the different security levels. Most important, train users. So no mistakable damages. Harden every component, including the operating system. Set up proper firewalls.  Set up proper network security, like use of the Oracle firewall that protects against unwanted SQL statements. We can compare SQL statement to a whitelist of acceptable statements. And then other database security features like VPD, the auditing as we will talk about, and other components to give you an overall very secure environment.  13:35 Nikita: Ron, what are the fundamental aspects of managing security only within the database… not including the operating system or the application?  Ron: So first, we have to have confidentiality. Confidentiality means that we need to make sure that all of the data is properly secured at a data level, whether it be both at the storage level, in the database for data usage, and we have many different ways of doing confidentiality management.  Number one, properly creating users, maintaining users with the proper password through proper authentication. And then setting up authorization that privileges may not be enough because if I give you select privilege, you can see every column, every row.  So I may need row level security, data redaction, data masking for duplication, and other mechanism to help us manage even subset of data for that particular security.  14:35 Lois: Ok… so that’s confidentiality. What’s next? Ron: Data integrity means that we need to make sure that data is not destroyed, whether it being addressed in the database, in memory, in data file, in backup, in exports, or during transmission in the network.  So we usually apply encryption and check-summing not only to protect the data, but also to validate, make sure it's not corrupted.  Next data availability, which means today, especially, we are 24/7 operation. And remember we talked about denial of service attack on a database. That usually attacks on the listener, because if the listener is crashed, nobody can connect.  We have to then utilize available tools and components like RAC to have multiple instances in case a particular host crashes. And I lose a particular instance. Data Guard in case my storage and a whole database crashes. The PDB and real-time PDB management with duplication, having a PDB standbys that are maintained and managed behind the scene. Using PDB snapshots, which are point in time. Preserve data that I can use it for restoring data at those particular point in time.  Backup recovery through RMAN or other backup recovery processes. So in case data is damaged, I can restore it and recover it. And finally, auditing. Auditing historically was always known as after effect.  16:09 Nikita: That’s what I was wondering… You only see what’s going on after something happens, right?  Ron: It also can be a deterrent when people know they are being audited, they're more careful, don't make mistakes. Try not to, of course, do anything you get caught. And today, this auditing can also be set up in a way that it cannot only catch what is going on. It can actually help us better secure data and have much better responses.  Now the problem with auditing has always been the overhead. That's why the unified audits that provides us with much less overhead for management can give us an extreme detailed audits. And then the new features allows us to even more reduce the amount of audits that are generated by only auditing at the column level and better protection for those audits.  By the way, in the older days, most auditing was done at the app, because we never knew who the end user the app is. But today with being able to have Active Directory mapped into the database and information passed between the two, all audits can actually come back centrally to the database.  17:21 Lois: So, to wrap up today’s conversation, Ron, can you just summarize database security for us? All the things we need to think about. Ron: So database security starts with making sure, number one, our network is secure and we are accessing the data through a very secure connection coming in from the user.  If required to be, could have a three-tier environment where the clients go through a first external firewall to get to the middle tier. Then from the middle tier go through internal firewall to get to the database, or if this is like a direct access and things like that, setting up secure network coming in through that like for administration, remote administrations, and operations.  Then, setting up proper authentication and authentication management, configuring detail, access control and setting up multiple level of security for data accesses, not just at the table level, even at the row and column level.  And building a complete data confidentiality by not only adding in storage encryption and all of the management of the data, even on components sitting outside the database, of course, we have Oracle components that can manage some of those for you, like sample backups, RMAN, and things like that.  And to get this complete data confidentiality, you also add in, as we said, an efficient auditing that can then describe any issues, tell us where the problem is, how it happened. And if we set up an audit system that is very focused, then we can even tie it up to triggers, to notifications.  So they're very quickly responded to, because the problem with audits has always been there is just way too much of them, therefore nobody ever reviews them to see exactly what has happened. So many vulnerabilities may go on detected until a major damage happens.  And that's how you can know that this is common out there in a lot of businesses when you hear in the news. And so and so company was broken in and so much data was stolen. Well, if proper security were set up and the network is being hacked in and proper alert system and automated system were configured to be able to catch these in a proper auditing real-time, then maybe corrective action could have stopped a lot of those damages.  20:04 Nikita: Thanks for that wonderful overview, Ron. In our next episode, we’re going to go through each of the new security features and try to understand how Oracle is tightening the screws around security. Lois: And if you want to learn more about what we discussed today, visit mylearn.oracle.com and search for the Oracle Database 23ai New Features for Administrators course. Until next week, this is Lois Houston… Nikita: And Nikita Abraham signing off! 20:31 That’s all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We’d also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.