Blue Core Research's "NO BULL" buyers guide to Database Auditing products - Part 13: Application user Identification

There is a common misconception about the value of application user identification. The reason for the misconception is the marketing of this feature by some companies, but we'll get into all that later. First lets examine the idea.

Most applications have a single database user that they use to access the data. To enforce security, these applications maintain an internal list of users and roles that they enforce. In other words – instead of using the database security features, that functionality is performed by the application. The result is that when you look at the database activity you see everything coming from a single user. An obvious requirement is to map the database activity to the application user as it is seen by the application.

There is, however, a little question that is important to ask – Why would you want to audit the activity of the application? The answer seems obvious – In order to audit the activity of the people using the application. However, this answer hides the critical question – Can you audit the activity of the users using the application by auditing the database activity? The answer to this question is not so obvious.

If your application is a small in-house application, chances are that the answer to the above question is Yes. It depends on the application, but in most cases you can audit the activity of the people using the application by auditing the database activity.

On the other hand, if your application is a large application like ERP, CRM and the like, chances are that the answer to the above question is No. The reason is that big application servers have big read and write caches to improve the performance of the application. As a result, most of the user activity does not get to the database and is stopped by the caches of the application servers.

The good thing about these large applications is that they usually have a nice auditing facility built-in so you don't have to rely on database auditing. There is still a need to audit those databases, but it is not in order to audit the application. The reasons can be to monitor the DBA activity, monitor change control, monitor changes in permissions and monitor users that access the data no through the application.

Now for the question that is probably still hovering in your mind - why would some database auditing companies develop and promote a feature to audit large application through the database? The answer is that it's because they developed this feature before they became database auditing companies. All these vendors used to offer performance tuning products, and decided they can be more successful selling their offering as database auditing. In the performance market it is very valuable to map a long running SQL in the database to the originating application user and screen. Unfortunately, when those performance tuning tools became database auditing tools, they did not redesign their products or change their technology to fit the new market - they simply repackaged their offering.

So be careful of a database auditing solution that tells you they support SAP, PeopleSoft and the like. Those applications cannot be audited using these tools. If your home-grown application does not have a cache, then you can use a database auditing tool to audit your application. And if this is your requirement, then make sure the tool you buy can be configured to recognize your specific application information and add this information to the audit data. Core Audit has been designed to be able to do this.

To learn more about Blue Core Research solution, visit http://www.bluecoreresearch.com.