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


Can someone help in preparing SOX security document for MS-SQL server production databases


Can someone help in preparing SOX security document for MS-SQL server production databases

Author
Message
Lina G
Lina G
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 193
Hi

iam anil, in process of preparing SOX security document for MS-SQL server which includes all the contents which are helpful for production database to be more consistent and can have track of all the changes done on it. I am looking for a document which can provide information that we are doing and to be done. Please send any checklist or some handy which can help the same.
anil kumar
anil.1004@gmail.com

Lina G
Database Administrator
Brandie Tarvin
Brandie Tarvin
SSC-Dedicated
SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)SSC-Dedicated (38K reputation)

Group: General Forum Members
Points: 38877 Visits: 9283

Anil,

Unfortunately, this is something that is changeable depending on what types of information you keep track of in your database and what type of business you have.

Part of our SOX documentation is a very strict SDLC process in which every data change and program change has to go through Test and QC before we can implement it in Production. We document the requirements of each change, getting end user approval of the requirements, and each stage of the testing requires approvals. 2 business people have to be in on the request. 1 as a sponser, the other as a requestor. This whole process ensures there are no potential financial changes being done at random.

Another part of SOX is reporting who has what access to the databases (and what roles they are members of) and writing up a "handbook" on how security is requested, the different reasons for granting / denying those requests and how it is finally implemented. We've only been doing this for a year, but so far we've kept all reports, going back to the beginning of the implementation. This helps us track who has access to make data changes and who can just look at things.

Lastly, we're automating all our reports (financial and otherwise) and generating them in PDF so the numbers cannot be easily altered by end users which would cause a SOX violation. The reports themselves have requirements written up on them which describes how we arrive at our totals and what numbers we're pulling up from what database/table/column. This way, if an auditor questions what a report is doing, we can pull up the requirements and explain it to him.

The big thing with SOX is to document your processes, which is the reason no one can really send you a SOX document. Since your processes are different from anyone else's, you're going to have to write up your own procedures. Hopefully, this will give you an idea of what you need to address in your own SOX initiative.

BTW, SOX is due to expire soon unless Congress renews it. You'll have to show that you made an attempt to abide by it while it was in effect (for later audits and lawsuits), but if it expires, then there will be a lot of people not even making the effort anymore.



Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
K. Brian Kelley
K. Brian Kelley
Keeper of the Duck
Keeper of the Duck (25K reputation)

Group: Moderators
Points: 25430 Visits: 1917
This forum thread also provides some guidance:

SOX and SQL server 2000

However, SOX compliance isn't a "cookie cutter" type of thing. So you'll probably finding yourself tweaking things based on what your internal auditors suggest / cite as weak controls. The best approach is to work with your auditors to determine the types of controls they are looking for and then building a security structure around that. External auditors who are validating controls are of limited use in this respect because they have to maintain independence. This is why it's not unusual for two external audit organizations to be brought in: one to help determine remediation steps and another to actually do the attestation.

K. Brian Kelley
@‌kbriankelley
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