In my last blog post, I discussed six important operating system security controls. Data stored in company databases has a similar set of risks to operating systems. With the right database-level permissions an intruder can add, modify, view, and delete data.

There are two key differences in the risk profile of databases when compared to operating systems, these being:

  • There are generally more users with direct access to database systems, these could be business users for data analytics work, developers for troubleshooting etc.
  • Database-level attacks such as SQL injection are a very common attack vector.

Looking back at my previous blog post, my view is that the six controls highlighted for operating systems are just as relevant to databases. I’ll chat through them below in the database context:

  1. Inventories: Maintain an inventory of databases. As for server operating systems, the main reason to keep a database inventory is to ensure that the critical controls highlighted are applied across all databases.
  1. Implement a jump box: Do all administration of databases from a specific jump box. This is to ensure that database administrative ports cannot be accessed from anywhere on a company’s network other than the designated jump box. This should prevent random attempts to access the databases.
  1. Allow no local users and implement complex passwords: Allow no local users. Only users (or groups) registered on the active directory should have access to the databases. Users registered in active directory are generally better managed, thus it is preferable to use this source than allowing local users. Ensure that the active directory users have complex passwords.
  1. User review: Review users with access to databases every six months, to ensure that their access rights are correct. This should also include reviewing the membership of groups with access to the databases.
  1. Monitor: As for operating systems,make sure all database accesses and access attempts are logged and sent to a monitoring system (SIEM) for analysis, review, and correlation with other security events.
  1. Patch: Patch database management systems for the latest vulnerabilities. This control is important to ensure that malware cannot exploit database-level vulnerabilities.

And one more:

As I mentioned above, a common attack vector is for hackers to use specially crafted SQL queries to access databases via web applications.

Other monitoring: I would suggest some form of monitoring on critical databases to detect unusual activity. This could be implemented by using a database access monitoring tool (expensive) or some simple system monitoring/triggers on key database tables. Monitoring can include interrogating database transaction logs for use of the common attack vectors such as “where 1=1” or database queries using the “*” operator or even access to view the database schema. Implementing this sort of control can give DBAs or the security team an alert of possible trouble afoot.

So that’s it, seven controls that if implemented well should give a reasonable level of security on databases.