Having worked in the security area for the last 25 years, I’ve seen security evolve from an after-thought to one of the most important factors considered during deployment.
In almost every organization, databases are where the most valuable information resides. Databases have lots of sensitive data in a concentrated form that is specifically designed to be easy to search and analyze. That makes databases a high-value target for bad actors and increases the priority for most organizations to secure the database.
Here are the top 10 steps that I recommend to secure a database:
- Don’t leave your system open to known vulnerabilities. Whenever a vendor releases a patch, that’s a signal to hackers that the vendor’s system has a vulnerability, and it’s a sure bet that attackers will decompile the patches to better understand the vulnerability that is being addressed. The time between a patch’s release and the incorporation of vulnerabilities into automated attack tools can be as little as a day and is seldom more than a couple of weeks. You should make it an organizational priority to shrink the time between the release of a patch and applying it to your database, application, or system.
- Understand your system configuration risk. Most successful database penetrations involve one or both of two vectors—a misconfiguration of the service that exposed the database, and a compromised user account. Today’s databases are complicated, with hundreds of parameters that can be adjusted depending on an organization’s needs, and several of which, if misconfigured, can open up the database to attacks. You should use vendor-provided utilities to help you evaluate configuration risks. At a minimum, you should scan database configuration as part of your security program at least quarterly, and look for configuration drift to spot the variations creeping into your environment.
- Know what and how much sensitive data is in your database. This will allow you to dedicate resources commensurate with the value of the data and the risk a compromise poses to the business. You don’t want to spend all your resources protecting a database that contains publicly available information such as items in a catalog when there is another database that contains your entire customer list including their personal data! An added advantage of knowing where your sensitive data resides is that you can use that information to craft policies for protection and monitoring (discussed further down).
- Minimize the amount of sensitive data you store. Data has value just as almost any other asset, but unlike other valuable assets, data can be duplicated without loss of fidelity and value. That means that the risk of breached data also proliferates along with the data. Most production databases have four or more copies—stage, user acceptance testing, test, and development. With four copies of your database, your risks increase significantly especially when non-production databases do not typically get the same protection as the production database. So, wherever possible, replace sensitive data from the copies of the database with realistic “fake” data that is good enough for testing and development purposes, but doesn’t put the organization at risk in the event of a breach.
- Pursue the utmost protection for database admin accounts. The most valuable database account to compromise is that of a database administrator. So control your privileged users – audit all of their activities (trust-but-verify), restrict their access to sensitive data, limit their privileges to only what is needed, and control their ability to connect to the database from authorized locations—just as you would for any other user. In most organizations, there is no reason for the database administrator to access application data.
- Implement Least-privilege. Since one of the most common causes of database breaches is compromised accounts, you should ensure that database accounts have the minimum necessary privileges in case they are compromised. Remove unnecessary privileges from users, but first you need to know what privileges your users have, what privileges your users are using, and then consider any unused privileges as candidates for removal. The concept of least-privilege isn’t new, but essential to lower your losses.
- Monitor logins to your database. This one is kind of obvious, but many do not do it. You want to monitor failed logins so you know if someone is trying to break into your database and from where. You also want to monitor successful logins so you know if someone is logging in when they should not be. Examples include developers misusing application service accounts; employees that have changed roles but still logging using service accounts; bad-actors connecting to the database from unauthorized IP addresses; and programs that aren’t officially approved.
- Audit sensitive operations and access to sensitive data. Data has value, which means someone is probably going to try and access/modify it. You should audit access to your most sensitive data and periodically check the audit records for inappropriate usage. You don’t need to read every audit record, but you should know which end-users, programs, and IP addresses are viewing or updating data. You should also audit the critical database operations including user/role management and bulk data movement. Most databases let you audit only relevant actions, reducing the amount of data that needs to be reviewed. Depending on the number of databases you need to audit, consider a Database Activity Monitoring (DAM) solution that will centralize those audit records or network statements in a secure repository and report on the collected data. Most DAM solutions will create different types of compliance reports including raising alerts based upon your policy.
- Encrypt your data in motion (TLS, Native Network Encryption) and at rest (TDE). Without data encryption, bad actors can simply bypass the database and its controls and attack the underlying storage, database files, or network connections to steal data. There was a time when some customers encrypted only the sensitive data due to performance implications, but now with all the optimizations using the chip instruction set, it is just better to encrypt all the data. This ensures you don’t miss anything, and handles those annoying cases where an application user inserts sensitive data into a column you didn’t consider. You’ll have the best coverage and performance using your database vendor’s native encryption as integration with third-party encryption tools can be problematic.
- Securely manage your encryption keys. Encrypting data solves the risk of an out-of-band attack, but introduces another problem—you now need to secure and manage those keys. Consider a Key Management System (KMS) to centrally secure, store, and distribute the encryption keys. As databases tend to exert a heavy load on the KMS, and have many different operating scenarios, ask your database vendor about which KMS solutions perform best with their database. It is strongly advisable to test whether the KMS can handle the load under all circumstances and supports encryption across your backups, high-availability, disaster recovery, clustering, and multitenant deployments.
If all databases were protected using these 10 recommendations, the security posture of the databases holding sensitive data would improve dramatically and the number of breaches would significantly shrink.
If you are interested in learning more about Oracle Database security, I encourage you to take a look at an e-book from my team: Securing the Oracle Database—A Technical Primer. It goes into more detail about the recommendations I’ve shared and is available on our website at https://oracle.com/securingthedatabase.
I’ll close by urging you to take a look at your databases—regardless of who your database vendor is—and make sure that your database security posture is at least as good as the security on your employee’s laptops. After all—databases are where some of your biggest risks live.