The same can be said for looking at configuration settings over and over, or resetting privileged accounts back to a secure baseline. But this is what database assessment is all about: ensuring the basic security measures are in place and effective. And it's the automation of these tasks that makes database assessment tools so useful. This post focuses on the operational tasks -- my next post will cover what you need to look for in assessment tools that support these functions.
It's the database privileges, misconfigurations, and vulnerabilities that are most commonly exploited by attackers. The three main defenses to verify database security are: assessing configuration, assessing user configuration, and patching the database.
* User Permissions and Roles: This includes default passwords, public roles of database features, databases owned by local administrator account, normal users with any administrative add/modify functions. Smaller firms may tolerate a DBA that has all privileges, but mid-sized to large firms do not. And just because you got these setting right last quarter does not mean that they stayed that way. Finally, you want to review both permissions assigned to each user, as well as user participation in each group. * Database Configuration: Every database platform is different, and every one will have specific options that require unique attention. But there are a handful of common settings that you need to pay careful attention to, such as any external code access, network SSL/TLS setup, and keeping functions or modules installed that you don't use. Review the database vendor best practices, because there are usually some handy tips there.
* Database Patching: Security issues are so common that your vendor will likely produces a security patch once a quarter. Sign up to get patch notifications so that you get pre-announcements and release details when the patches are ready. You should get into a routine to determine if the patch is relevant to you, and if so, have a test environment so you can quickly verify that the patch or workaround does not kill some critical application or function. Most zero-day attacks, such as SQL injection and buffer overflows, don't have specific workarounds so you need to patch quickly. Task injection and authentication escalation may have temporary workarounds, so look for those.
This is really the bare minimum you need to look at -- I am not getting into advanced settings, blocking, or automated patching. But you need to get the basics right. In my next post I'll talk about tools.
Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.