HELP! SOX OUT OF CONTROL!@!
-
I am being told by our auditors (company is 1500 employees), the I have to audit all production database servers (12 oracle, 7 sql server). What they want is to set up a process that monitors all admin roles and users. Any activity by these roles or users have to be sent to another secured server for someone from Audit to monitor and review.
1) Has ANYONE been told this by their auditors that have to do SOX. I have asked for other companies that are currently doing thins, but they cant' seem to come up with any names of companies or phone numbers to call.
2) Is any one doing this now? Only way I know to do this is to run several profiler sessions to dump out data. How to get it to a secure remote server??? Don't know yet.
Despite the lack of information on exactly what to report, and auditors that can't actually show me someone doing this, management has made it a top priority.
Very frustrated with SOX, looking for others that have been throught this.
If you do SOX, watch out. Been told that each Auditing company gets to make their own rules.
Joseph
-
there is a fascinating read here at SCC where the SOX auditors tried to say that the DBA must not have access to the production servers:
http://qa.sqlservercentral.com/forums/shwmessage.aspx?forumid=161&messageid=116604
which is patently ridiculous, because the DBA's primary responsibility is to manage the server and it's data.
the issue is directly related to a person who does not know what the job entails, trying to tell you how to do your job. They cannot tell you that an audit trail needs to be sent to a separate server, for example; they need to tell you that an audit of changes needs to be demonstrable.
What they want is an audit trail for any changes that occur. you could most likely do that with a consistent backup strategy, and maybe one of the tools from imceda or redagate or some of the others that have log trolling capabilities.
Make them say what they are trying to track, rather than how to do your job. Then resolve the issue with known strategies or software solutions.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
What you need to do is setup a "locked-down" environment so that all regular DB/Application activity is controlled via SP's and SQL-Application roles, and that all DDL activity is controlled via 'restricted userids - with passwords in enveloples, etc'.
SOX is about seperation of duties and about establishing procedures for controling updates....and proving the processes are repeatable and coherant and gap-free.
SOX is not about continually logging activity. It is about proving that the previous state of the database can be transposed forward to it's current state by reapplying all documented DDL changes that have occurred in the meantime.
Auditors are great for saving "there is a problem". ..but not so hot at "suggesting a solution"....they also aren't too hot on paying for this sh*t.
-
We already have seperation of duties and process in place for with change request forms that require the requester's and their manager's signature. Then of course after I finish, I sign it, attache appropriate documntation, scan everything and keep in for 3-7 years.
We have all users locked down as tight as possible and yet let the application run. There are absolutely no admin roles assisgned outside of the DBA's (their is only 2 of us). We don't do any developement. We do the data changes in production via scripts sent and approved by the analysts of the system.
We don't have passwords in most systems. We use OS authentication. No system or analyst knows the SA passwords. We don't even really know the SA passwords because we don't use them. The passwords are contained in a centrally located, moinored, and encrypted file.
We have specifically been asked to create a process that will put files/database on a secured server that I can not get to, that contains all changes of data and database structures made by administration accounts. An example... There was a data change made by me, requested by an analyst to fix some problem. The data entry did not have a proper control, and bad data was entered. Affected 200 or so rows. I am suppose to have an automated system that pipes all the information (who did it, when, old data, new data, related data structures, ect...) to this other server via flat file or other database. Then someone from security is to review that information for "suspect conditions" and investigate.
We brought up the fact if I design, maintain and implement such a system across SQL Server and Oracle, then I am also the person with the knowldege to bypass such a system. They did not seem to care. They want something in place and quickly.
One of their suggestions was to create triggers on the tables and other objects to do this process. We have systems with over 20K tables and 15K database objects.
Has anyone setup C2? I have to attempt something and looking at writing continous profiler sessions or look into C2 auditing.
Joseph
-
Personally speaking, I'd stay away from C2 since it logs *everything*. We did a trial on just one system and extrapolated that outwards to calculate that we'd be producing upwards of 60GB of logging data daily for just this one system. Add to that the need to then analyze the data and report on the 'good' stuff then you're looking at a fairly hefty chunk of work.
I ended up putting together a combo home grown and commercial based process utilizing ApexSql Log which allows me to concentrate my reporting on the stuff that matters. Granted there are still holes in the system but, as a DBA with Alpha and Omega type permissions on the server I think that no matter what there are *always* going to be exploitable cracks.
Just my 2c worth is all...
-
I think Lowell hit the nail on the head with his reply. Since they do not have a comprehensive knowlegeable of SOX, and they are taking off on a tangent, you need to get written specifics from your auditors. Have them set out their standards so that you can document them. Wandering benchmarks make for a real nightmare, when you keep changing the process to meet a moving target.
Been there done that!
Paul
-
Been pushing for specifics. Get none back. This issue hit the board of directors last month. Heavy push on this from top down. Auditor say they might not "sign off on the books" if we don't show them we are trying to implement a solution. They said it is not their directive to provide solutions, but uncover the gaps and make sure that get adequatly (sp) filled.
Right now, we have to show a plan for the solution. Upper management is trying to push back on the auditors to approve each stage of the solution. That way we don't work to put something in place and get told it is not adequate.
OH, the one new thing (today) is that the files/databases must be reviewed by members of our security team. It will be their job to decipher the information and investigate further when needed.
Anyone else having to go through this for SOX?
Joseph
-
This is the first time, but unfortunately probably not the last time, that I've heard the acronym SOX in relation to audits as opposed to Boston or things you put on your feet. My experience of audits and auditors is about as good as those outlined above. SOX sounds like more job creation for auditors, I doubt it will do much good, after all, look at the role auditors played in the collapse of Enron.
PS - SOX - Sarbanes Oxley - I get it now!
-
Good points have been made. However, auditors are in a position to attempt to define SOX however they wish.
Management must be bright enought to realize that that a 'success' criteria must be specified up front and that they (management) have every right to push back on the auditors and demand some responsibility and accountability from them. After all the company pays the auditor.
Our auditors have asked "How do we know that the DBA isn't changing production data?" Doesn't matter whether or not the DBA will be able to get to the data.
They also say things like "OK, you got an access exception report emailed to you. Prove that you opened it (meaning a digital timestamp)."
You can either write your own tool or buy one. The ones that I have looked at either read the transaction log, use a modfied Profiler session with some kind of agent installed on the database server, or they examine the SQL packets on the network.
Whatever the solution is chosen, management must require the auditors to sign off on it. There will be a dollar cost associated with all of this and management must realize that. No free lunches here.
For what it is worth, one of our developers maintains that SOX is really an economic stimulus package. Maybe he's right.
-
I fully agree. We have said for sometime now that SOX was Congress's "Auditors Full Employment Act". The took away IS consulting and had to give them something else.
We do reports by exception. Failed login, errors, ect. Problem is that is not good enough. I am looking at profiler sessions. I have started looking at Replication/Publication with modified filters.
My major frustration with this, is that anything I can come up with to put in place, I can easily circumvent as well. SO, How can I sign off on the control as "effective"?
Joseph
-
SET WAY_BACK_MACHINE ON
Time for ISO-9000, ISO-9001 audits.
SET WAY_BACK_MACHINE OFF
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
The quote "They said it is not their directive to provide solutions, but uncover the gaps and make sure that get adequatly (sp) filled."
I think this point is the key.....mgmt must evaluate the problem, consider the solution(s) proposed and give an opinion that the solution is a fair-minded attempt. A solution can be a iterative one, whereby over-time the process is improved.
There is no 100% solution for this. I believe that all SOX requires is that iun good-faith, all reasonable and practical steps are taken to made to solve the seperation-of-duties problem at hand.
Re the change log, where data-fixes had to be applied mid-stream, I think the answer there is 'for dev-team/rollout team to go back and start the change again...using 100% scripts'.
-
Management determines what is/is not in SOX scope unless they choose not to do that, then one is left at the mercy of the auditors.
The SOX specific veribiage in the law is at 100,000 ft.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply