It’s a problem that I see organizations struggling with every day. An audit finding has come down requiring the monitoring of privileged users in databases containing sensitive or regulated data.
From the outside, this seems simple. Get a list of privileged users and log whatever they are doing. However, as folks dig into this, the first question they have to ask is who are the privileged users? And that’s where the trouble starts.
What exactly is a privileged database user? It’s probably not anyone and everyone with access to the system. Maybe it’s only the database administrators, but what exactly does that mean? Membership in a DBA or SysAdmin role?
That can be very misleading, since DBA level privileges can be granted directly to a user without any role membership, or new roles with names like Not-A-DBA can be created with DBA equivalent privileges.
Maybe a privileged user is anyone with write access to the database? But that tends to include everyone, since it’s been pointed out by database security researchers many times in the past that creating a read-only database user is essentially impossible, due to all the write privileges that are typically (and often irrevocably) granted to PUBLIC (that’s everyone in the database).
Even with a firm definition of what makes a user a privileged user, the problems don’t go away. Just because a user is not privileged today, does not mean they won’t be privileged tomorrow.
Actually creating and maintaining an accurate list of privileged users in an enterprise full of databases can be an impossible task.
There is another way forward though. One that is simple to define, implement, and maintain. One that meets the letter of regulations and audit findings, and one that ensures that no matter how or when a user obtained their privileges, that their activities in the database are tracked.
The answer is to pay attention to the activity first, and who did it second.
While it’s hard to define what a privileged user is, it is easy to define what privileged activity is. Changes to the structure of the database (DDL) and changes to the privileges in the database (DCL) are both clear areas of privileged access that must be tracked.
Changes to data (DML), particularly changes to sensitive or regulated data is another clear area of privileged access. Perhaps direct connections to a database via an ad-hoc query tool, or via MS Access or MS Excel are considered privileged access.
Check out the latest Insider Threat White paper in the Application Security resource center.
In the end the exact definition of what is and is not considered privileged access is going to be dependent on the organization, the auditors involved, and the regulations that govern protection of the stored data.
However, in every case, these definitions are fairly straightforward to establish, and once they are have been laid out, it’s easy to implement monitoring based on the activity type, instead of based on the user running queries.
There are a number of ways to actually implement this monitoring. All DBMS vendors provide some native auditing functionality.
For the major database vendors, these audit systems allow configuration based on the commands being issued, not just the user issuing them.
Native database auditing systems have a poor reputation though as a performance nightmare, so DBAs often fight hard against enabling them. There is another equally important reason not to rely on native database auditing.
Those systems are under the complete control of the DBA, the exact people that we’re being asked to monitor. It is hard to prove the integrity of an audit trail when the persons being audited can enable, disable, and reconfigure the audit system at will.
A much better approach is to use a 3rd party database activity monitoring (DAM) tool. These products tend to have little to no impact on database performance, and the good ones on the market are setup such that they are not under the control of the administrators being monitored.
I fully expect that in the not too distant future, IT auditors will require the use of trusted 3rd party systems to implement privileged activity monitoring, purely for the segregation of duties benefits that they bring.
If you’re facing a situation where you’ve been required to monitor your privileged users, make things simple for yourself by turning the problem on its head and monitoring the privileged access.
For more information on Database Activity Monitoring, visit the Application Security, Inc. website at www.appsecinc.com.