April 28, 2005 at 10:25 am
Does anyone know where I can find details specific to SOX & SQL Server security? I'm trying to determine what SOX says about security of SQL Server if it says anything at all.
Thanks
Kindest Regards,
Just say No to Facebook!April 28, 2005 at 3:49 pm
Disclaimer: this is all just my personal interpretation, based on my personal understanding of the issues, based on my personally banging my head on SOX issues the past few months.
SOX (The Sarbanes-Oxley Act of 2002, http://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf for a copy) says nothing about SQL Server. It says nothing about databases. It says nothing about IT. What it does say (and I'm still wading through that .PDF, so I probably am wrong about significant details--but not very) is that business entities that are publicly owned, or that have publicly held debt, have to be a lot more financially responsible than they have been (viz. Enron and other grande scams of recent times). To that end, they have to (a) keep track of (audit) the information that underlies their financial statements, and (b) be able to prove that they are doing so, because otherwise (c) anyone whose job title begins with a "C" (CEO, CIO, etc.) could end up in jail.
It also seems to spell out that the only way to prove you are SOX-compliant is for an outside auditor to come in, check you over, and say that you're good. (If not, you're in trouble, though the nature of that trouble is not particularly specific.) Who can audit you? Why, people that they say can audit you. Who are "they"? Why, the Public Company Accounting Oversight Board (http://www.pcaobus.org/), which was established by the SOX act (see part 1 of the SOX act).
So what does any of this have to do with SQL Server, let alone databases? Darn good question. The logic goes that if the data in your databases is used to draw up the companies financial statements, then they want to know (a) who is able (not skilled or inclined, just able) to go in and monkey with the data, and (b) are they or are they not actually doing so. Fair enough questions, of course. Unfortunately, this is pretty hard to do for reasons that rapidly become apparent when you actually sit down and work out what you have to do and what you have to do it with. But that's a subject for another thread.
This has gotten a bit long winded. I suppose the best summary is, consult with your SOX auditor (and it sure seems that if you don't have an authorized SOX auditor, you're not compliant), determine what they say you need to do, and then do your best to do it. Skilled and articulate use of sophistry will prove invaluable. Since it's all new and--once it gets down to the logical and physical implementation levels--very vague and thus open to wildly varying interpretations, you're not at all likely to find any "carved in stone" How to Soxify your System articles out there. As proof, I find no articles on the subject here in SQL Server Central, and there's precious little Microsoft has to say on the subject.
Good luck!
Philip
April 29, 2005 at 5:28 am
SOX requires that the data used to generate the financial statements is created and modified only by approved and documented processes. Any details relating to SQL Server (or any other software) are inferred, and as such are open to interpretation.
Donhttp://www.biadvantage.com
May 2, 2005 at 8:43 am
Thanks to both of you for your response. Let me ask you both this and if anyone else owuld like to chime in then please do so.
If I have a database on an instance of SQL Server that cintains fiancial data used to prepare financial reports and I leave that instance of SQL Server setup in a way that allows for non-authorized users to access the DB via the sa login then would that indicate that I am in violation of SOX? I know that this scenario is justs bad, very bad for other reasons. What I'm focused in on is whether or not this type of setup could be a SOX compliance problem.
Thanks
Kindest Regards,
Just say No to Facebook!May 2, 2005 at 9:29 am
Hi Ed,
It would be hard to imagine compliance for the situation you outlined. Of course, if everything was documented and data modifications had an audit trail...
Maybe you should speak with your compliance officer. Or just Google "sox compliance" and start reading up. Remember that if the requirements were well defined and easy to understand, we wouldn't have to pay so many extra people!
Good luck!
Don
Donhttp://www.biadvantage.com
May 2, 2005 at 7:29 pm
Ed -
There is a chance you will be OK with this if the data your Users are accessing with the 'sa' account is just Report data and not the actual core Financials. I recently survived a 6 month SOX audit and the focus was on access to the core Financials in JD Edwards. There was little interest in the Reporting application (Cognos) as it was a derivative of the core Financials. There was no interest in the CRM system (Pivotal). All were on a different SQL Server backend instances.
Remember, their job is to see that there are procedures in place to adequately protect shareholders from 'Cooking the Books'. 'Cooking Reports' is a completely different thing.
If this Sysadmin access is granted on a server that also holds the core Financials, then you've got some explaining to do. Your procedure might indicate that access is restricted to 3 Users and only from a single workstation located in the locked Payroll area between the hours of 8 and 11 AM while in the presence of at least two comapny Financial Officers.
Then again, you might just create a SQL Server role (if you can't stop to figure out what permissions are needed then even 'dbo' would be better than 'SysAdmin), Add your users to the Role, turn on SQL Server Success/Failure Login auditing and call it a day. For my recently completed audit, that most likely would have passed as compliance (with copious screenshots and a document of course).
One more bit of advice... be responsive to their requests, provide what they ask for and put all docs in a repository for later reference. You will be asked to provide many of the same things again and again by different auditors.
This is all survivable! Best of luck!
Stuart
Stuart
"Chance is always powerful. Let your hook be always cast. In the pool where you least expect it, will be a fish" - Ovid
May 3, 2005 at 6:50 am
A big thanks to all who have responded. The situation I describe is unfortunately something I have no control over but still have to work with. In this scenario the IT group is tasked with handling the SQL Servers. I can only pass along info in hopes of there making changes based on that info. And with all of your responses I now have better info to pass along.
Thanks again!
Kindest Regards,
Just say No to Facebook!Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply