Security Zones of Control
Securing an Oracle Database is critical in keeping your sensitive data safe and staying compliant with the many new privacy regulations proliferating across the world. Your data is extremely valuable– that could be intellectual property, financial data, personal data about your customers or staff, or (more likely) a combination of all three. Because data is valuable, you need to guard it against theft and misuse.
To keep data really safe, you can lock it up and bury it – but since this data is used for business purposes –that means users and applications need to use the data and connect to the database. You need to safeguard that data with security controls that restricts access to the data according to your policy.
To do this you’ll need to do three things:
1. Assess the system to determine its current state and develop a remediation plan
If you’re an Oracle Database customer, then your existing investment in the Oracle Database already gives you the features and utilities you need to assess your database and identify areas for improvement and risk reduction.
2. Detect attempts to access data outside of policy and identify anomalies in data access – almost all database activity is repetitive, so anomalies are frequently a leading-edge indicator of attempted data theft.
3. Prevent access to data that doesn’t go through the database control mechanisms – sniffing traffic over the network, reading the underlying data storage layer, or misuse of database exports and backups. Block inappropriate access to data through control mechanisms that consider the context of the access, not just the identity of the account accessing the data.
Oracle provides industry-leading capabilities for each of these security control objectives. Our team can help you identify the right technical enforcement for virtually any control objective.
How are databases attacked?
Databases are valuable repositories of sensitive information, and a data thief is almost always going to target the data in databases in attempts to steal data. Before we think about defending against these types of attack, let’s look at how the attacks normally occur.
Databases don’t just operate in a vacuum. They’re constantly in use, meaning risk exposure is often multiplied. A database is accessed by users and applications. In most cases, there are copies of databases for test, development, and staging for many reasons. Databases persist data into a storage medium, and run on servers with operating systems and peripherals. All of these are managed by administrators, and administrators are a hacker’s favorite point of attack due to their high privileges. If they can compromise an administrator account, they are in with elevated privileges and – in many cases – no controls over what they can do.
If the attackers can’t compromise an administrator account, they often compromise an end user account. Lower privileges, but often still with access to some data, or useful as a stepping stone to get to that desired administrator access through SQL Injection attacks
Applications also make an attractive target. They are frequently more exposed than the database or database server, often even available from outside the corporate firewall.
Speaking of those firewalls, if an attacker has managed to penetrate to the internal network, they may choose to go after data traveling over that network. This type of attack is much less likely to be detected than attempts to access the database directly.
Another popular attack is against the underlying data files, database backups, or database exports. Here again, if the attacker is successful, they may be able to steal the entire database without ever having to try to log into it.
If none of those things work, perhaps the database has an unpatched vulnerability – in many cases there are automated attack toolkits that help exploit those vulnerabilities
And don’t forget those non-production copies of the database. In many systems, the test and development instances are just clones of production, and have almost no security controls.
So, how do we defend against all these types of attacks?
An effective database security strategy is going to take several different security controls, all working together. We’ll divide our controls up into the categories frim earlier: Assess, Detect and Prevent and then also Data Driven Security – a special category of security controls focused on fine-grained access control of application data within a relational database.
Start by using Oracle Database Security Assessment Tool (DBSAT) to assess the database configuration and identify deviations from best practices. If the database is configured poorly, then other controls may not be effective
Next, remember those users and applications? They all log in to the database, so we may want to use Centrally Managed Users (CMU), a database feature that connects the database to Microsoft Active Directory. We may also want to consider Enterprise User Security (EUS), another database feature that lets a database talk to Oracle’s own directory services. In both cases, database users and roles are externalized from the database into a LDAP directory.
We probably want to authenticate those users with something stronger than password – the Oracle Database supports Radius, Kerberos, and PKI certificate authentication. Going back to DBSAT, we also want to know who those users are and what privileges they have – and DBSAT will tell us that.
In addition to what privileges a user has, we want to know what privileges they are actually using – and Privilege Analysis (PA) will tell us just that. We can use privilege analysis to identify privileges and roles that aren’t being used, and revoke them from user accounts to lessen the attack surface in the event an account is compromised.
As database clients begin to push data into the database, and retrieve that data for reporting and analysis, we have to worry about securing the data as it travels over the wire. For this we’ll enable network encryption.
We’ll also want to have an idea what type of data is stored in the database, and DBSAT will help us here with sensitive data discovery.
Since that data is eventually being persisted on disk, in backups, and in exports we’ll want to protect it from attack there. Here is where Transparent Data Encryption (TDE), part of Oracle Advanced Security comes into play. TDE will encrypt data on the operating system, in storage devices, in backup and export files. And when data is encrypted, that means there are one or more encryption keys that we need to protect and distribute securely – for this we’ll use Oracle Key Vault (OKV). OKV understands the Oracle Database in an enterprise architecture and can help make TDE key rotations easy and protect previously used keys when older backups and files need to be restored.
Remember those administrators with privileged access to data? We’ll want to protect against them as well, and for this we’ll use Oracle Database Vault (DV). Database Vault lets you separate the duties of database administration from access to data within the database. Database Vault also protects against a compromised application server, locking down application accounts so they can only access data from within the normal context of the application.
When data is accessed from outside of the application, we may want to provide additional protection for high-value data columns like credit card numbers or taxpayer IDs. For this we can use Data Redaction, also part of Oracle Advanced Security, to hide sensitive data, even on the fly as it leaves the database
And for those non-production clones of the database, we’ll use Data Masking, part of Oracle Data Masking and Subsetting Pack to simply remove sensitive data from them, replacing it with realistic looking “safe” data that does not present a security risk, but still allows application development and testing to continue
We’ve done a lot to protect the database, but we also want to be sure we can detect attempts to break in and steal data. For that we’ll configure auditing within the database, and feed audit events to a centralized audit vault for analysis, reporting, and alert generation.
We’ll also use Database Firewall, part of Oracle Audit Vault and Database Firewall, to examine incoming connections and SQL statements for anomalies and violation of policy – and if we choose to, we can go one step further and actually BLOCK out of policy activity with the firewall. Of course, events from the Database Firewall flow into the Audit Vault server for analysis, reporting, and alert generation.
Finally, we may choose to exercise fine-grained control at the data row or column level for application users. For this Oracle provides a variety of features including Real Application Security (RAS) and Oracle Label Security. This cell level access control allows multiple applications to be developed and have a consistent application user authorization model for data access – saving application development time and effort.
All of these controls working together create the Maximum Security Architecture. Most of the things I’ve talked about are features of the database, available to any Enterprise Edition customer. A few are extra-cost options or products.
Maximum Security Architecture in the Cloud
One of the great things about the cloud is the options it gives you. If your database is running in the Oracle Cloud, then you also have Oracle Data Safe available. Data Safe provides several features to help you secure your Oracle Databases, and can take the place of DBSAT, Audit Vault, and Data Masking.
Other options like Database Vault and Transparent Data Encryption are also available for you in the cloud, and for most cloud services (like Oracle Autonomous Database), are included in your subscription at no additional charge. In many cases, they are automatically enabled and configured for you.
This means that implementing the Maximum Security Architecture is even easier in the cloud.
Remember, the goal of most cyberattacks is to get to your most valuable asset – your data. Use the Maximum Security Architecture as a guide to help protect this asset.