July 5, 2007 at 12:57 pm
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
Lina G
Database Administrator
July 6, 2007 at 7:11 am
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.
July 6, 2007 at 8:32 am
This forum thread also provides some guidance:
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
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply