Safeguarding Databases Against Insider Threats

February 24, 2016
| |
6 min read

While phishing, malware, distributed denial-of-service (DDoS) and similar types of external threats rightfully receive significant attention from organizations, they only represent one aspect of the threat equation. Insider threats are the other piece of this puzzle and can be equally damaging.

In fact, the “2015 Cyber Security Intelligence Index” showed that more than half of data breaches are caused by insiders, including employees, third-party contractors and partners. In this article, we will review the key insider threats affecting your database assets and discuss concrete strategies for defending against such threats.

Insider Threat Types: Intentional Versus Unintentional

Insider threats can be divided into two main categories: intentional and unintentional. Intentional insider threats are typically carried out by individuals who are motivated by financial gain. For example, in one incident recorded by the Privacy Rights Clearinghouse (PRC), a former financial planner stole sensitive information from approximately 3,000 clients and used it to open new accounts, make purchases and receive cash advances. Client names, Social Security numbers, contact information and financial account information were exposed.

Although popular, financial gain is not the only motive. Retaliation by a dissatisfied employee or state-sponsored espionage are some examples of additional motives for intentional insider threats.

Unintentional insider threats are typically the result of human error such as misconfiguration or careless behavior by administrators. An example of misconfiguration is setting the authentication mode for a database to exchange user IDs and passwords with remote clients in cleartext (unencrypted). Such credentials can be easily intercepted by an attacker to impersonate a legitimate database user and steal sensitive data.

An example of careless behavior is using live customer data in test and development environments. This leaves sensitive data exposed to testers and developers who are typically not authorized to view such information. According to the Cyber Security Intelligence Index, nearly half of insider threats are unintentional.

Read the white paper: Get smart to shut down insider threats

Intentional Insider Threats Affect Your Database Assets

According to Verizon’s “2015 Data Breach Investigations Report,” privilege abuse remains the defining characteristic of the internal data breach. In a database, system administrators and database administrators possess very powerful privileges that, when abused, can result in significant damages.

The following are examples of the most dangerous privilege abuse those actors can perform.

Downloading Sensitive Data by the Database Administrator for Financial Gains

By design, the database administrator has full access to all tables in the database. They can abuse this privilege to extract sensitive data such as credit card numbers, Social Security numbers and product plans to sell on the black market.

To avoid alerting network security monitoring tools when downloading large amounts of sensitive data, a knowledgeable database administrator would download this information in small pieces over several days.

Downloading Sensitive Data by the System Administrator for Financial Gains

While system administrators do not typically have access to the database, they do have access to the underlying file system where the database tables are physically stored. A knowledgeable system administrator would bypass the database interfaces altogether and fetch the data directly from the underlying physical files.

Alternatively, system administrators can abuse their privileges to impersonate a legitimate database user and download data through the normal database interfaces.

Performing a Dangerous Change by the Database Administrator for Retaliation

By design, a database administrator can execute changes to the database. Disgruntled database administrators can perform a dangerous change such as planting a malicious stored procedure that gets invoked after they have left the company to show their employer how important they were.

There is virtually no limit to what a stored procedure running with administrator privileges can do in terms of damage, including deleting rows, deleting tables or revoking application privileges to create denial-of-service (DoS) issues.

Unintentional Insider Threats Affect Your Database Assets

Unintentional insider threats are attributed to human error and represent nearly half of all insider threats, according to the “2015 Cyber Security Intelligence Index.” Although unintentional, this type of insider threat can also cause significant damage to an organization. The following are some of the most dangerous examples.

Database Misconfiguration

Misconfiguration leaves the database vulnerable to attacks. For example, sensitive data exchanged with remote database clients over a cleartext channel is vulnerable to network packet sniffers, which are freely and widely available on the Internet.

Another example is the selection of a weak authentication method such as client authentication. Under this mode, the database server does not challenge the user for authentication since it trusts the client to have done so.

Use of Production Data in Test and Development Environments

While we appreciate the need for having meaningful test data, the use of production data in these environments exposes sensitive data to testers and application developers. These roles typically do not have the authorization to view such data and the act would be in violation of many privacy laws.

Uncontrolled Use of Shared User IDs

In some organizations, the database administrator account is shared by different users. This creates an accountability problem because the database audit logs would show the shared user ID next to all actions performed, making it nearly impossible to pinpoint which individual completed an action.

Bypassing the Change Management Process

Sometimes database administrators choose to bypass the change management process to speed things up or please an application developer. Although this is not intended to do harm, it often has the same result. For instance, revoking a database privilege without due diligence may create a DoS problem for an application that requires that privilege.

Decommissioning of Storage Media With Cleartext Data Without Sanitization

Hard drives break. If the database is not encrypted and the organization does not follow a formal physical media sanitization process, then sensitive data will be exposed to anyone who gets their hands on it after it has been decommissioned.

Safeguarding Your Databases Against Insider Threats

Winning the battle against insider threats requires a comprehensive and proactive database security strategy. The strategy must address both the intentional and unintentional threat use cases. In this section, we will review the key tenets of this strategy and describe an example implementation.

Database Vulnerability Assessment

A misconfigured data repository is vulnerable to attacks. A vulnerability assessment would compare the data repository configuration settings against industry best practices such as the STIG or CIS benchmarks, and it would alert the administrator about any misconfiguration issues and how to fix them.

Database Activity Monitoring and Protection

Continuous and real-time monitoring of database activities is critical to counter insider threats. A policy could be put in place such that when the database administrator is suspected of abusing privileges, an appropriate action is taken. Example actions include auditing the activity, alerting a security officer, redacting the query results the database returns to the administrator or blocking access altogether.

Database Anomaly Detection

Anomaly detection is critical for countering certain types of insider threats. For example, when a system administrator impersonates a database user, actions would appear legitimate to the database from an access control perspective. However, the activities would most likely be different from those of the legitimate user, and anomaly detection would flag them on the security officer’s dashboard.

Similarly, the activities of a legitimate user abusing privileges to download a large amount of sensitive data in small pieces over a longer period would also be flagged as anomalous.

Test Data Masking

Production data must be masked before it can be used in test and development environments. Masking must be format-preserving and context-aware so applications are tested with meaningful data.

For example, an application expecting a Visa credit card will most likely have logic to confirm that the digits provided represent a valid Visa credit card number. Similarly, an application relying on a database referential integrity constraint would expect the primary key and foreign key columns involved in the constraint to be masked exactly the same way.

File Activity Monitoring and Protection

Continuous and real-time monitoring of file activities is critical to countering insider threats. A policy could be put in place such that when the system administrator abuses privileges to access the database indirectly through the file system, an appropriate action is taken, similar to when a database administrator abuses privileges.

Database Encryption

Encryption is another option to counter privilege abuse by system administrators. When the files are encrypted, their content is meaningless to anyone without the encryption keys. Additionally, database encryption is critical to protect against accidental sensitive data disclosure when physical media is decommissioned without proper sanitization.

Shared User ID Management

Shared user IDs must be managed carefully in order to maintain accountability. A shared user ID must be checked out before it can be used to access the database, and it must be checked back in when the borrower has finished the work.

All check-out and check-in activities must be fully audited. This information can then be correlated with the database audit information to derive exactly who did what and hold users accountable for their actions.

Separation of Duties

Clearly, the database security controls cannot be in the hands of the database administrator. Database security and database administration need to be vested into separate individuals to counter privilege abuse.

Read the white paper: Get smart to shut down insider threats

 

Walid Rjaibi
CTO, IBM Security Guardium