Database Security Platforms are incredibly versatile – offering benefits for security, compliance, and even operations. The following are some classic use cases and ways we often see them used:
Monitoring and assessment for regulatory compliance
Traditionally the biggest driver for purchasing a DAM/DSP product was to assist with compliance, with Sarbanes-Oxley (SOX) almost single-handedly driving the early market. The features were mostly used in for compliance in a few particular ways:
- To assess in-scope databases for known security issues and policy compliance. Some regulations require periodic database assessment for security issues, policy (configuration) compliance, or both.
- To assess databases for entitlement issues related to regulatory compliance. 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 like users assigned multiple roles which create a conflict of interest. This can be evaluated manually, but it is far more efficient to use a tool if one is available.
- To monitor database administrators. This is often the single largest reason to use a DSP product in a compliance project.
- For comprehensive compliance reports spanning multiple databases and applications. Policy-level reports demonstrate that controls are in place, while other reports provide the audit trail necessary to validate the control. Most tools include such reports for a variety of major regulations, with tailored formats by industry.
Web application security
Almost all web applications are backed by databases, so SQL injection is one of the top three ways to remotely attack them. Web Applications Firewalls can block some SQL injection, but a key limitation is that they don’t necessarily understand the database they are protecting, and so are prone false positives and negatives.
DSPs provide a similar capability – at least for database attacks – but with detailed knowledge of both the database type and how the application uses it. For example, if a web application typically queries a database for credit card numbers, the DSP tool can generate an alert if the application requests more card numbers than a defined threshold (often 1).
A DSP tool with content analysis can do the same thing without the operator having to identify the fields containing credit card numbers. Instead you can set a generic “credit card” policy that alerts any time a credit card is returned in a query to the web application server, as nearly no front-end applications ask for full card numbers anymore – they are typically left to transaction systems instead.
We have only scratched the surface of the potential security benefits for web apps. For example, query whitelisting can alert any time new queries or patterns appear. It is increasingly common for attackers to inject or alter stored procedures in order to take control of databases, and stored procedure monitoring picks up attacks that a WAF might miss.
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.
Change management
Critical databases go down more often due to poor change management 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 by DSP reduces the likelihood of a bad change, and provides much deeper accountability – even if shared credentials are used. Every administrator action in the database can be tracked and correlated back to a specific change ticket, with monitoring showing the full log of every SQL command – and often return values as well.
Legacy system and service account support
Many older databases have terrible logging and auditing features that can crush database performance, when they are even available. Such older databases are also likely to include poorly secured service accounts (although we concede that stored plain-text credentials for application accounts are still all too common in general). DSP can generate an audit trail where the database itself does not offer one, and DSP tools tend to support older databases – even those no longer supported by the database vendor. Even modern databases with auditing tend to impose a greater performance impact than DSPs.
They can also audit service accounts – generic accounts used by applications to speed up performance – and even alert on unusual activity. This can be especially useful with even a simple rule – such as alerting on any access attempt using service account credentials from anywhere other than the application server’s IP address.
And with that, we have wrapped up our series on Database Security Platforms.
Comments