Introduction to database security tools for the enterprise

Database activity monitoring

The most significant database security component is activity monitoring, or what are commonly called database activity monitoring (DAM) platforms. They capture all SQL activity to the database -- including administrative actions -- and analyze the statements for behavioral, contextual or security misuse. These tools can detect and alert on a wide variety of threats, and most have the capability of blocking certain statements -- though few organizations use this blocking capability.

The reason most organizations roll out DAM into their security arsenal is not just for the ability to detect threats, but because it is the best way to collect an accurate trail of events for regulatory reporting and to provide data and data filtering options not available with built-in database audit logs. Put it this way: DAM is to databases as security information and event management and Log Management are to general IT security and reporting.

The downside of DAM is it takes time to deploy local agents, it can be expensive to acquire, and it requires periodic updates to policies to ensure alerts are being generated on inappropriate activity. In addition, firms may choose not to block database queries, as it causes unintended side effects in application state and data consistency.

It's worth mentioning here that there is a small subsegment of the DAM vendor space that offers more security-focused platforms, commonly called database firewalls. These are similar to a Web application firewall (WAF) in that they are a proxy that sits in front of the database -- as opposed to the application -- and are intended to block malicious traffic. And, like WAFs, database firewalls digest incoming traffic and filter based upon specific security rules, as well as query whitelists and blacklists.

For cases where databases have direct exposure to external (i.e., Internet) threats, database firewalls will block SQL injection attacks and filter unwanted queries, and are useful in cases where it is too costly or time-consuming to change the application. Similarly, there are proxy services that redact or mask query results depending upon the users credentials. Called data masking, these platforms change the query results sent to a user if the request is deemed questionable, or if a user lacks sufficient permission to see all of the data they've requested.

Database assessment

Database assessment tools, sometimes called database vulnerability assessment tools, check database configuration settings and patch levels. Unlike generic server and endpoint assessment tools, database vulnerability assessment tools check operating system-level settings as well as configuration information stored inside the database -- the latter being invisible to server assessment tools. These database-focused tools contain thousands of pre-built checks for specific misconfigurations and the presence of common attack vectors, covering not just vendor-recommended database security best practices, but industry-recommended security models as well.

It's true that some databases come with basic security checkers embedded with their general admin capabilities. But the unspoken truth of the matter is that third-party vulnerability assessment products are critical, as they include details and provide information that many database vendors choose not to address. While a vendor may alert organizations to specific database vulnerabilities and associated patches, the third-party vendors provide additional workarounds, reconfigurations and analysis the database vendors do not. They will, for example, recommend the removal of database options known to be security hazards.

Furthermore, most of the third-party tools are designed with non-technical stakeholders in mind. So while they provide the needed separation of duties between security and DBA teams, people who are not well-versed in database technical details can still verify the correct policies are in place and enforced.

Encryption

Most databases offer encryption capabilities, usually to encrypt specific columns or cells within a database. These internal facilities are usually governed by the application; it's the application that must be augmented to call the database encryption libraries to encrypt or decrypt data. This type of encryption, often called application-layer encryption (despite it being provided by the database), has fallen out of favor due to performance and integration issues.

Today, the majority of database customers use what is known as transparent database encryption, or TDE for short. TDE acts on all data, encrypting data to and from the database as it is written -- or read -- from disk. And, somewhat counter-intuitively, it is faster than application-layer encryption. That being said, the great benefit of TDE is that it's invisible to the user, the application and even the database itself. As a result, encryption can be added without any changes to the application code or database queries. The outcome is disk files and all database archives are secure from prying eyes.

The weakness of TDE is twofold: It requires a solid key management system to ensure data security, and any credentialed user or application will be provided decrypted data upon request. So while TDE tackles most data-at-rest security challenges, it needs help to validate access and usage.

Masking and tokenization

When an organization doesn't trust a database, or can't ensure the database will remain secure over time, how does it ensure data remains secure? It could delete it, but any application that relied upon that data will no longer function. As an alternative, two data-centric security tools have made waves with Payment Card Industry Data Security Standard compliance and test data management.

Given that these database security tools embed security and compliance knowledge into the pre-built policies, they lessen the burden on security and operations teams so organizations are not building rules from scratch.

Those two technologies are tokenization and masking.

Tokenization replaces sensitive data with a surrogate that looks and acts like the original, in the same way that a subway or arcade token acts like cash. This means applications continue to work as normal, but there is no threat if the data is lost or stolen. Tokens only have value as a reference to the original value, stored in a different -- highly secured -- database called a token vault, and accessible only by select users.

Tokens are great for substitution of a single data element, like a credit card number, but what about cases where an organization has lots of complex data used for analytics?

Data masking -- sometimes called static data masking -- is a technology used to exchange sensitive data sets with masked copies, but still preserve the aggregate value of a database. A "mask" is a means of obfuscating data, such as shuffling values in a salary column, or substituting real names with those randomly pulled from a phone book, or even changing someone's date of birth to a few days off from the real value. In this way, the real data is obscured, but the masked copy preserves enough similarity to the original that reporting continues to provide meaningful results.

Tokenization and data masking replace sensitive data with a surrogate, removing sensitive information altogether, which in some cases, obviates the need for database security altogether.

Procurement

Database security tools are provided by the database vendors, third-party security vendors, and found in open source distributions. But with database security software, the old axiom "you get what you pay for" holds true. Vulnerability scanners and log data mining tools are commonly inexpensive -- or even free. But they typically lack a depth of features and functions, offer poor user experience, and don't accommodate customization needed for most companies. Activity monitoring and encryption are very difficult security tasks, with the better tools produced by third-party security specialist firms. You get much better out-of-the-box capabilities, but at considerable expense.

Training and support

Given that these database security tools embed security and compliance knowledge into the pre-built policies, they lessen the burden on security and operations teams so organizations are not building rules from scratch. However, each type of database security software -- be it tool or platform -- is suitably complex enough in deployment and management that some training is required.

In all cases, the third-party vendors of these security tools offer training, usually bundled in the purchase price. And, in most cases, two to five days is sufficient to get up to speed with platform usage. While these platforms do require periodic management and maintenance, those can reasonably be assumed by in-house personnel without the need for a highly skilled, dedicated support team.