Sox Lessons Learned

Posted: October 6, 2008 in Database Recovery

Sorry for the short note today. Working on finishing up my presentations for the SQL Connections show in Las Vegas the second week of November. Anyways I am doing two sessions there one is what you should be doing your first 30 days on the job as a SQL Server DBA and the other is Lessons I have learned from going through a few SOX Audits. This got me thinking to something that happened to me once that I just floored me, and well I thought I would put it up on my blog since this is sort of a diary type thing minus the whole mushy stuff.

The year was 2005 if I remember correctly. The reason I think it was 2005 was because it was the second year that I had to go through a SOX Audit and the first year they were required was 2004. Anyway, I had spent the morning in my office meeting with 2 auditors. Neither of them was very savvy with SQL Server, but they did understand that there needed to be guidelines on whom and when can people see what data in the database. More importantly not who can read the data but who can insert and change data. See we had a meeting not 3 months before where I finally after years of work convinced the CTO that Developers did not need and should not get access to write data in production. The CTO was a developer and was having a difficult time understanding the need to control and keep the environment safe (whole separate story). The end result was that I finally had the CTO agreeing that there was no reason that a developer should need to see production data. I was explaining this to the auditors and showing them how we had lock all the accounts of the developers to development. I thought that this was a good thing and that the VP would be happy that we dodged a bullet just a few months before the audit.

Well it was not 30 min later that one of these young buck auditors went over to the developers in the company and asked them for some assistance. The developer agreed seeing how the request was pretty simple, and he didn’t think it would get done. The request was this. The Developer was to request that the permissions on his read only account in production to be changed to DBO access. Not just a Write account but DBO. The Developer sent an e-mail and my over efficient team was more than happy to meet the needs of a developer, the account was granted permissions and within 20 min. I was standing front and center in the VP’s office.

The end result after talking to my team was that they were tired of getting beatings everyday from our development team, see normally the way this would have worked would have been that my DBA would have said no. Then the Developer would go to his boss and tell management how my team was just being difficult. Then the Developer CTO would come over and ask why my team was being a road block. Fair question, the problem was that the CTO cared more about pushing new things into production rather than protecting the existing data. The policies of the company were written but being enforced by an individual that had 0 concerns for the systems and security until something broke and he was being asked about them. I am not so much bitter about this as I am dumb founded.

How do you balance development of new tools against the stability of what is in place.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s