SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Looking for SOX-Security Details


Looking for SOX-Security Details

Author
Message
YSLGuru
YSLGuru
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1832 Visits: 1665

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!
Philip Kelley
Philip Kelley
SSC Eights!
SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)SSC Eights! (859 reputation)

Group: General Forum Members
Points: 859 Visits: 232

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





landrake
landrake
SSC Journeyman
SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)

Group: General Forum Members
Points: 91 Visits: 20
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.


Don

http://www.biadvantage.com
YSLGuru
YSLGuru
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1832 Visits: 1665

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!
landrake
landrake
SSC Journeyman
SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)SSC Journeyman (91 reputation)

Group: General Forum Members
Points: 91 Visits: 20

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




Don

http://www.biadvantage.com
sqlgiant
sqlgiant
SSC-Enthusiastic
SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)SSC-Enthusiastic (199 reputation)

Group: General Forum Members
Points: 199 Visits: 202

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
YSLGuru
YSLGuru
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1832 Visits: 1665

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!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search