Database security products: A buyer's guide
A collection of articles that takes you from defining technology needs to purchasing options
Database security tools are incredibly versatile, offering benefits for security, compliance and even operations. These products, available from third parties, provide a level of database security well beyond what relational database management system (RDBMS) vendors offer customers.
This is especially true of database tools in the realms of database assessment (also known as database vulnerability assessment), encryption, database compliance and test data management, tokenization and data masking.
The following are some classic use cases and ways organizations often use security add-ons to boost database security. As databases are used to support just about every application and business function within enterprises, you find databases everywhere. It's because of this diverse set of uses that we see a similarly diverse set of requirements for database security.
Use case #1: Compliance
Compliance is far and away the biggest driver for database security expenditures, and why most firms apply add-on security technologies only to those databases that fall under regulatory scrutiny. The regulations tend to fall into two different areas: antifraud, which is driven by Sarbanes-Oxley, and the Payment Card Industry Data Security Standard for customer privacy, which is driven by Gramm–Leach–Bliley Act and various state privacy protection regulations.
Database security is also driven by a third motivator related to (but unspecified by) compliance: cost reduction. It's often easier and less expensive to secure the database -- or the data it manages -- than secure all of the applications and networks attached to these databases.
Database security tools used to meet compliance run the full gamut. For example:
- Assessment scanners to periodically inspect in-scope databases for known security issues and (internal) policy compliance. Some regulations require periodic database assessment for security issues, policy (configuration) compliance, or both.
- Permissions audit to ascertain if segregation of duties is in place and to look for over-subscription of entitlements, as defined by the various regulations. While all vulnerability tools can assess database platforms to some degree, no non-database-specific tools can perform credentialed scanning and assessment of user entitlements. This is now often required by certain regulations to ensure users cannot operate outside their designated scope, and to catch issues such as users assigned multiple roles, which can create a conflict of interest. This can be evaluated manually, but it is far more efficient to use a tool if one is available.
- Database activity monitoring (DAM) to monitor privileged users, which is often the single largest reason to use a DAM product in a compliance project. These generate logon/logoff reports, as well as track all system activity and alert when administrators and select privileged users view sensitive information.
- Using DAM for comprehensive compliance reports spanning multiple databases and applications. Security information and event management (SIEM) platforms don't collect the necessary events, and built-in database tools do not provide consistent cross-database collection or policy enforcement. Policy-level reports demonstrate that controls are in place, while other reports provide the audit trail necessary to validate controls. Most database security tools include such reports for a variety of major regulations, with tailored formats by industry.
- Tokenization and masking to remove sensitive data and thus remove the database from compliance scope. If sensitive data is replaced with a non-sensitive surrogate, the compliance requirements are removed as well.
Use case #2: Web application security
A SQL injection is an attack against a database. While the attack enters through an application, it is a database attack, and it has remained one of the three most common attack vectors for the last decade. Almost all Web applications are backed by databases, but since it's the application that faces the public, databases are often an afterthought and left unprotected by application developers. Web application firewalls can block some SQL injections, but a key limitation is that they don't necessarily understand the database they are protecting, and so are prone to false positives and negatives.
DAM products and database firewalls address these issues without costly re-writes to application code to remove SQL injection and scripting vulnerabilities. The costs of altering enterprise applications to address security issues often outweigh the original development cost of the application; and in other cases, the fixes would take decades with current staff levels. This is why firms have looked for add-on tools that address these attacks.
For example, query whitelisting can alert admins any time new queries or patterns appear, or can learn what the application should send and automatically block everything else. Some tools on the market even communicate violations back to a WAF, either for alerting or to terminate suspicious sessions and even block the offending IP address.
Use case #3: Change management and internal audit
Critical databases go down more often due to poor change management during patch and upgrade cycles than due to attacks. Unlike application code changes, administrators commonly jump right into production databases and directly manipulate data in ways that can easily cause outages. Adding closed-loop change management supported (i.e., trouble-ticket systems) by DAM reduces the likelihood of a bad change, and provides much deeper accountability -- even if shared credentials are used.
Assessment tools scan databases and allow security and compliance teams to validate the database administrators are doing their jobs. DAM is used for closed-loop validation that administrator actions correspond to a specific change ticket, with monitoring showing the full log of every SQL command -- and often return values as well.
DAM is commonly used for event collection and analysis, seeding compliance reports and SIEM systems so audit teams have event data they need. And an increasing number of companies are using DAM and dynamic masking to protect these systems from malicious queries, so security policies may be implemented without changes to the application or supporting database.
For firms worried about insider theft and fraud, this later form of validation gives non-DBA's full view of database maintenance and patching efforts.
Use case #4: Legacy database security
Face it, there are a lot of databases in house that were designed and deployed before anyone was thinking about data or database security software. These databases were designed with dependencies on dangerous things such as externally stored procedures or using Social Security numbers as primary database keys. But these database instances persist because they support critical business processes. The problem is, even if an organization can find someone who still understands how it all works enough to modernize their legacy applications, and then get the budget to do the work; the hardware and software are so old they fall over as soon as you touch the system.
One of the growing areas for database security tools is legacy database security. These are especially well-suited for cases where an organization can't secure a database server because the required changes would cause the database to stop working.
Who benefits from database security software?
For most enterprises, they are well beyond asking if they need to protect relational database or RDBMS. After all, there is a laundry list of data breaches and compliance requirements that have settled that question.
Organizations, meanwhile, have also found their network and endpoint security products do not cover their databases. And they've discovered the hard way the generic security offerings from RDBMS vendors -- which claimed database coverage -- offered substandard policies and spotty event collection. In essence, generic products can't differentiate between normal and malicious use, nor assess configuration and patch levels sufficiently, because they lack data and analysis capabilities.
Compounding the issue is that the stakeholders who need this data (e.g., security and internal audit teams) lack the technical experience to gather it. IT and database administrators are reluctant to alter applications or databases for fear of destabilizing these systems.
It's here database security tools provide the real benefit; they allow users to provide security and audit what they need without changing the actual database or negatively impacting the database's performance. The real challenge is selecting the right database security software to address the issues an organization faces, which we will discuss in our next feature article in this series on database security tools.
Be sure to check out the other features in this series: Part one is an introduction to database security tools for the enterprise.Part three outlines nine steps you should take before purchasing database security products. Part four compares the top database security tools on the market.
View this checklist to ensure you're following the basics of database security.
Learn how to identify data egress points in databases to prevent malicious data exfiltration