Can anyone direct me to a plain-English resource that explains the impact of SOX on database administrators? I’ve been researching this for a while now and cannot find a straight answer.
Specifically, I need to know how long to retain database audit records, but I probably need other information as well.
Thanks.
Have you tried: http://www.s-ox.com/
This site seems to have some good information also : http://obian.com/riskmitigation.shtml
The problem with the SOX laws seems to be that nobody, especially your external auditor, is authorized to proactively advise you on how to comply with the laws. Of course, most of that is most likely “cover-your-ass” BS, but the fact remains that you really can’t ask for advice or help from the people most likely able to give it.
This site SEC Adopts Rules on Retention of Records Relevant to Audits and Reviews explains retention rules for financial information. It’s as good a place to start as any.
Have you been to http://www.sarbanes-oxley.com/ ? Looks like it’ll either be exactly what you’re looking for or a phenomenal waste of time.
The whole thing is confusing as hell…there are a lot of resources out there, but some of them seem to contradict each other, and a lot of folks still don’t seem to believe SOX applies to their company…I work for an IT staffing firm, and half of the folks I talk to (IT directors, CIO’s and HR people) either don’t know what SOX is ( :eek: ) or aren’t worried enough about it to care. Makes me wonder where the next Enron is going to pop up…
Good luck.
Isn’t the standard SOX guideline “Keep everything forever but give access to no one”? 
I’ve been to those sites, and several dozen more like them. My confusion derives from the fact that no one seems to have any actual answers but just rehashes the same dire warnings and warmed-over advice.
As far as I can tell, from the point of view of a database administrator, I have to worry about two things:
Securing the database to prevent unauthorized access, creation, or modification of that data. This is part and parcel of my job already, so it’s no big deal.
Preventing surreptitious modification of data by authorized users. Since we cannot prevent authorized users from modifying data, we must therefore log all changes to critical data. I can do this. But I cannot figure out how long to keep the logs. Since the logs associated with creating a gigabyte of data may take up two additional gigabytes, space management becomes a real issue.
I suspect there are other issues I should be worried about, as well – I just don’t know what they are.
Any help out there?
As someone mired in the opening stages of a comprehensive SarbOx-compliance audit,* I suspect that “plain English” is anathema to the whole concept of the thing. It was supposedly designed as a response to the crappy auditing that allowed Enron & Pals to get away with financial murder, but in reality it turns out to be a sop to those same auditing firms to let them charge ever more outrageous fees for longer and longer audits that bear less and less reality to the day-to-day requirements of running a business. </grouchy>
Anyway, the issue you mention, “surreptitious modification of data by authorized users,” is one of our biggest headaches right now. We’ve been pushing back really hard on the auditors, under the philosophy of, “Hey, at some point in the chain of authority somebody has to be trusted to hold the master keyring,” but we’re not getting a lot of traction. So I feel for you.
*And won’t it be fun a hundred years from now when people on the SDMB Mark 42 are asking, “What’s the etymology of this word ‘sarbox’ that means 'getting raked over the coals by relative know-nothings?”
Our current strategy is to keep the audit data forever.
We have been using a product from Lumigent called “Entegra” for more than a year now on SQL Server - the Oracle version just came out and we haven’t started using it yet. Entegra makes it easy to select tables for auditing, and auditing includes who accessed it (for SQL server, gathered by an agent which was a hook into a low-level trace function), updated it, etc. We don’t audit selects but you can. We audit all changes to most tables - you can easily exclude working/bulk-load tables and even filter down to the column level. The product also makes it easy to archive the repository, which is necessary if you have a high-volume of transactions (database size doesn’t matter, what matters is how many transactions you have).
I don’t have a full cite on hand, but SOX Section 802 calls for records to be stored for seven years, during which time, they must be noneraseable and non-rewritable.
CD-R manufacturers must be loving this.
Now that’s interesting. Do you know how SOX defines the concept of “record”? Because I gots me a few hundred million of them, all on read/write media.