I'm totally new to this stuff. I'm told that the actual SOX "defining document" is thousands of pages and not practical for me to read through. I'm also told that SOX, in practice, is what our auditors tell us what we need to do. (My company is already talking to auditing companies that profess SOX expertise.)
Any idea where a DBA can start to learn about SOX?
P.S. Around our company, our frontend applications control authentication. Often the application talks to the database using a single account, for all users, using the app. We can't begin to trace at the database level who is doing what. I'd bet SOX will have something to say about this approach.
We are going through SOX as well. Have already implemented a lot of "SOX" items. SOX for our company includes but is not limited to:
SOX, HIPAA, Segregation of duties, Plain ole common sense, Bill 481 (reporting security breaches), etc...
We have already locked down access to SQL data by role. Each role is associated with an AD (windows) group. Direct access to write to tables is via the application account BATCH and real-time WEB transactions. Direct access is also available via "emergency accounts".
Code management is also a biggy. Can code be installed into production without getting tested, approved, source code stored, etc...
Proper testing is/has been/will always be around nuff said.
Written approvals from the asset owner, project manager, etc... for good ole CYA and accountability.
Auditing is also HUGE. Can you track who dun what, when, why, how? If not WHY not and will your CIO signoff on it? If not looks like somebody is adding code to applications. It is VERY easy to capture Environ$("COMPUTERNAME"), Environ$("USERNAME"), etc...
These are a few of many FAVORITE things...
I don't think anything is documented. We are implementing SOX too and I am guessing most of these "rules" are coming from someone's hiney. It's all subjective at this point.
AJ makes some great points though. I think if you follow what he is saying, you will survive any SOX audit.
If you are look at different SOX applications and are thiking of buying one i use to work for a compnay that developed SOX software so i can put you in touch with them.
Sox docuemnt is actually a group of practices that specific to different kinds of companies and the departments in the company.
As far as auditors, they get to make up the rules of what needs to be audited and at what level. This is where management gets involved. We 3 sets of auditors. Internal, External Consultant, External Audit. The consultant was suppose to help us formulate our own rules and practices (since the external can not make direct contributions, only tell us if we pass or fail). What gets my goat, is we went through this and ended up with 380 items for evaluation from the consultants. Our first audit (2 years ago), the external auditors said more than 1/2 were unacceptable or not needed. We not have 92 items. Each item contains 3 to 25 questions/lines.
Long and short, work with auditors, when they are unreasonable, it up to management to push back.
Most practices are easy to do and after you been through it, the quarterly stuff does not take long. We only have 1 item that is not acceptable. Protecting the systems from the DBA's (thats me). We have eveluated several products. Each would satify audit, but I showed them how I can get around them (I am not a good hacker), and each cost $100,000 plus.
I hope this can be of some help to get people going:
You have probably noticed that auditors in general (there are exceptions) do not currently seem to have a great deal of depth where IT knowledge is concerned. This may mean that they are not necessarily digging deep. That is likely to change over the next few years though as SOX is having them beef up their skills. If you want to know what they're learning about your field check out http://www.isaca.org/Template.cfm?Section=IS_Audit_and_Control_Training_Week&Template=/ContentManagement/ContentDisplay.cfm&ContentID=22705, specifically the Database Security and Audit course.
If you want to see additional SOX documentation from an auditor's point of view go to www.isaca.org. I recommend starting with the "IT Control Objectives for Sarbanes-Oxley" pdf. It's about 100 pages long, but it's a surprisingly quick read.
Work with the auditors as much as you can. They usually want to see you succeed even though the process can be painful from time to time.
Interesting reading Junkmail.We had to go through SOX recently. Fortunately, I didn't have to read a whole lot of information. I just got a bunch of files from the auditors telling us exactly what requirements were required on our servers and I just followed those.
Here's some of the things we do to ensure SOX compliance:
Have an owner for each application who is responsible for approving any changes to the application.
Each database should have an owner for the data. This may be differnet than the owner of the application, if there ar emultiple databases associated with a single application. Data owners approve access to teh data.
Document the risks associated with each system, and have the application owner sign the risk assessment.
Document the controls that mitigate the risks for each system. The application owner should sign the list of controls
Where possible, track which ID made changes to data, particularly on tables with critical data.