April 2007 - Posts

Compliance, the DBA and the 4 W’s

 Compliance is a word that can bring a chill to a Production DBA, especially in the financial sector. I was fortunate enough to be able to say a few words the other day about a product that can help the DBA in the quest for compliance.

Now let's be very clear about this now, compliance is more than just buying a product or writing a number of process documents. You need the whole buy in and it has to become a way of life, just like a controlled environment, which you'll also need.

Compliance isn't just SOX, most companies store data which is sensitive for one reason or another and we as production DBA's are responsible for the protection of this data - we can't pass the buck or show a sloping shoulder to the matter of data protection. It's not just personal financial data, medical details, credit card numbers, national insurance numbers, names and addresses - all this data needs protecting and as recent events have shown encryption may not always be the whole answer - the actual loss/theft or data is sufficient regardless of whether the data is actually used or sold on, you just wouldn't be able to say with any certainty.

The financial penalties for data loss or security breaches can be high and as a DBA would you wish to be associated with such an event?

I see compliance as the 4 W's - Who? When? What? Why?

As a DBA these would be the questions you'd be asked - could you answer any of them with total conviction?

I'll just sidestep into the area of basic database security for a while - it's readily accepted that it's far easier to drop an employee into a company to steal data than it is to hack through a firewall.

  • Do your applications log on as SA or dbo ?
  • Do you grant users datareader and datawriter?
  • Do you blanket grant exec on all your procedures to your users?
  • Do you store user data in a table called users or creditcard or bankdetails?
  • Do you have columns called password, creditcard, NInumber, or in a similar manner?
  • Do you use copies of your production databases in development environments?

Whilst I agree security through obscurity isn't the total answer, using obvious names is a bit like bolting the doors and leaving the windows open!

btw if you can say yes to any of the above be glad I'm not an auditor!!

You're probably wondering where this is all leading - well it's towards a product called Compliance Manager by Idera



So am I using this product? Yes.

Why do I like it? It leverages the skills and knowledge of the SQL Server DBA by using SQL Server and Reporting Services. It's easy to install, doesn't require a dedicated server, although you might want to use one, however you could use a dedicated instance thus saving on SQL Server licensing costs.

I've evaluated a number of other products from other vendors and none of those come near to matching what  SQL Compliance Manager has to offer, please don't ask me to name names.

Very important - this product does not use triggers, so you won't kill the performance of your server, in fact it general terms this is a low impact application, much in the same vein as SQL Diagnostic Manager


One of the questions often asked by auditors is who audits the DBA's - " who watches the watchers " , well SQL Compliance Manager will audit the DBA's, this means the DBA can be protected because the product can show what the DBA did. Of course SQL Compliance Manager will audit itself, so there's no coming in via the back door !!

You'll note I've not listed what the product does in detail, because it audits what you set it to audit, and it's best to speak to the helpful folks at Idera or download a demo.

As a footnote - no I'm not being paid by Idera,  but I do care about compliance and security, especially the lack of it, I'm hopeful that SQL Server 2005 will improve the quality of the security model of many third party applications, but to be honest I'm doubtful.

As a Production DBA I'm in favour of products that help me in my duties

Posted by GrumpyOldDBA with no comments
Filed under: