Where does Database Auditing Belong?

I've had so many good discussions with vendors and DBAs recently it's really hard to know where to begin. I'm going to start with the most recent talk I had with a vendor (not going to say just yet) because it's still very fresh on my mind. And those of you who know me know how important that is. We were talking about DB auditing and where the responsibility actually belongs. As we all know, auditing has traditi

I've had so many good discussions with vendors and DBAs recently it's really hard to know where to begin. I'm going to start with the most recent talk I had with a vendor (not going to say just yet) because it's still very fresh on my mind. And those of you who know me know how important that is.

We were talking about DB auditing and where the responsibility actually belongs. As we all know, auditing has traditionally been the role of the DBAs. DBAs are the gatekeepers of the information inside the DB, and whenever an anyone needs a list of the DB access for the past whatever period of time, they go to the DBA. Afterall, he is the one who manages the access to the system. And he is the one who setup and manages the auditing mechanism. And he's the one who probably wrote the reports you're looking at. So why wouldn't you go to him? He's the go-to guy for the DB, isn't he?

Now, what this vendor is proposing is that the DB auditing is to be moved out of the hands of the DBA and into the hands of the compliance officer (CO). Their argument is that the separation of duties is more or less driving this. When a CO or auditor asks the DBA for an access report they have no way of knowing if the data has been doctored to hide something or not. I don't really think that separation of duties has much to do with it though. A DBA would be able to alter that data no matter who was driving the reports. If I know the system is being audited and I do something I'm not supposed to, then I'll cover my tracks the same way regardless of whether I'm producing the reports or not. So from that aspect, I think they're way off base.

However, I do think they're more or less on track in their approach. What they're doing is taking something like DB security and starting to wrap real BI around it and turning CO's into consumers of that data. If you look at the classical role of DBAs in a BI environment, this holds more true to the model. DBAs do what... they provide end users with the data they need to make decisions. Be they analysts, managers, whatever, they have their client tools for accessing and analyzing their business data. Well, what if your business is the security access of the DB? Then you should have client software that supports your role.

I've worked in several healthcare orgs and at none of them was I ever asked to help analyze the business data. So why would I be asked to analyze this business data? Well, like I said before... traditionally this was the role of the DBA, and with good reason. Data's a complicated beast and it can be hard to sink your teeth into it. DBAs typically understand more about the nature of the access being reported on, and they know what's going on with the processes.