<b>SARBANES-OXLEY SUCKS</b>
We are currently putting processes in place to comply with the Deloitte & Touche interpretation of Sarbanes-Oxley for our internal audit department, and for certification of compliance with Deloitte & Touche. As a DBA, I normally don't complain about processes and have introduced many at my company; however, today I read the proposed functions the DBA would have in my organization if they pass the version currently being considered.
Database Administrator: The DBA will insure the integrity and performance of the database environment. The DBA will not have access to security functions. The DBA will not have access to the physical servers. The DBA will not be able to view production data.
?????? Do these people have any clue about reality? I can't view production data. My developers can't view production data, neither can anyone who is considered a developer. So we have nobody able to view the data, who can fix a bug should it occur. I can't have access to the physical server. Now this is a problem since I currently manage ALL the 27 SQL Servers we have including patches and critical updates. I can't have access to security either, so everytime I set up a new user, or need to add a user to an existing NT Group I need to forward the change control to the NT Security group. I can then do my job. That's fine with me.....less work.
In addition, all fixes need to go through a full SDLC including emergency bug fixes. Think about this before you say it sounds reasonable. This means I not only have to provide a dev/test/staging/prod environment for releases. I need to have the ability to clone production quickly to produce test/staging environments for the bug fixes as well. This will mean buying space for an entire new environment that can be quickly cloned with SnapView for testing of fixes seperately from the normal process. While this environment is being build, and everyone on earth is taking time to test the bug fix, the users are just screwed. I understand we need controls, but this is going WAAAAAAAAAY overboard.
The thing that bothers me the most about this is the incredibly stupid and inept people dictating these processes. We have non-technical people giving us their interpretation of the law as it regards technical matters. Notice it's an interpretation that will benefit ONLY THEM!!!!! That is where the real conflict of interest resides, not in the off chance that some developer could copy someone's phone number down and call them on the phone at night. The head of our internal auditor department said that we must “think like criminals” and think that our developers are. I believe the criminal is the one who slantingly interprets the law solely for the purpose of creating jobs for themselves to the point it erodes shareholder value by limiting the service levels provided by IT/IS departments. That is criminal.
Favorite words used: 8 (complain, reality, WAAAAAAAAAY, overboard, stupid, inept, screwed, Touche) --I just love that word.
Mean level (1-10): 4 (If you are an idiotic auditor completely out of touch with reality, I'm sure you'll find this somewhat mean.)
Education level (1-10): -2 (You really can't learn anything from these people. You are dumber after you sit in their presence.)
Entertainment level (1-10): 5 (Don't worry. Your turn is coming.)
Legacy Comments
|
Greg
2004-06-29 |
re: <b>SARBANES-OXLEY SUCKS</b> "The head of our internal auditor department said that we must “think like criminals” and think that our developers are" Nice... Funny that I'm not seeing any developers/DBA's being prosecuted by the Gov... Just CEO, CFO's, etc... :0 I guess we all REALLY know who should be treated like criminals. :0 |
|
Jim Bolla
2004-06-29 |
re: <b>SARBANES-OXLEY SUCKS</b> As a developer, nothing motivates me to be productive like being treated like a criminal. :/ |
|
Tara
2004-06-29 |
re: <b>SARBANES-OXLEY SUCKS</b> ---The DBA will not have access to the physical servers. The DBA will not be able to view production data. Now that would make Maggie and Poncho happy. ;-) |
|
Brett
2004-06-29 |
re: <b>SARBANES-OXLEY SUCKS</b> Ours is better...in order for a near shore developer to get access to one of my dev boxes, I have to make (I'm sorry), they have to make a request through their security blanket which in turn sends it over seas, where it's handled by our system liasons, which in turn asks mu boss if it's ok...and then it travles back so the security (wet) blanket then sends the request to my boss, who then gives it to the corp tech security group... No wonder they want to offshore..it'll be much quicker... Wonder if they have the same procedures? |
|
Steve Gall
2004-10-26 |
re: <b>SARBANES-OXLEY SUCKS</b> I help IT departments comply with SOX. The rule is that DBAs (or developers) cannot CHANGE production data; as that would be a conflict of interest. One of the key points of SOX is that there is an audit trail. It's OK for a DBA to make changes to boxes/systems, but there has to be a way to ensure that the "system" (your boss signs-off, there is an audit log that is reviewed, etc.) that leaves a "paper trail." SOX, in the end, is about visibility into who is doing/has done exactly what, in regards to systems that can impact financial statements. SOX will become bigger than the tax code, and it's here to stay. You'll survive. |
|
Derrick Leggett
2004-10-27 |
re: <b>SARBANES-OXLEY SUCKS</b> Actually, a DBA can change production data. They just cannot change production data they developed. The "rollout" process must have the DBA as the person or member of the release team releasing the database code to production. The business must then signoff on that process and there needs to be an audit stating what was rolled on each release and who rolled it. We already have this in place. If SOX becomes bigger than the tax code, it will hurt the financial statements of the very companies it's trying to help. It will hurt them severely. And, you can't say that anyway, because the courts will ultimately decide how far-reaching this poorly written law will be carried. |
|
ME
2004-11-11 |
re: <b>SARBANES-OXLEY SUCKS</b> I am an auditor working on sarbanes and let me tell you i do this all day and my life is way worse off. sarbanes sucks. |
|
Mike
2005-07-07 |
re: <b>SARBANES-OXLEY SUCKS</b> The cost of SOX compliance for our company has cost us profitiability for 2 quarters running now. Cannot wait to see the 2nd quarter results.... |
|
teD
2005-11-30 |
re: <b>SARBANES-OXLEY SUCKS</b> You're a SOX auditor and your life is worse ? I'm way down the totem pole at a manufacturing facility - SOX never should've touched me - but it has badly. SOX has become 2 things : Thing 1, the 3rd grade in a liberal teacher's classroom. Tommy was mouthing off so nobody gets to go out to recess now. Thing 2, we're now running our business to make the auditors happy. It no longer has anything to do with common sense, logic, GMPs, efficiency, or profit. |
|
Who cares?
2005-12-10 |
re: <b>SARBANES-OXLEY SUCKS</b> Yep...Controls need to make sense. There is a balance that needs to be found. This takes time and we're not all there yet. If you have the time, I am on my soapbox... I am ex-Big 4 - Tokyo. Why ex ??? The hours. Gotta better gig, more money and time for a life, but I have profited from what I learned from my clients and my Big 4 firm... What works and what is just not effective, and I want to share... So, regarding production change control audit issues I just read posted within this site... I was on the frontlines auditing the major investment banks for four years in the financial district of Tokyo and have firsthand experience when SOX went down on a global basis. That was a frantic time for all sides. A real freak show. To those SOX auditees that have legit concerns I say...push back and defend it with sound risk analysis and formal control solutions. Auditors love procedures with signatures, BUT only present what works for you and yet can be defended. Here's the deal from the top players (not me)...With the DBA pros I dealt with (and was humbled by in knowledge and yet all of them were cool/patient enough to share such knowledge with me...remember most Big 4 IT staff auditors are puppies right out of college...pure generalists following scripted audit programs backed with mere academic theory) at my former investment bank my clients...I mean, guys making 200k+ a year because they were very good...Well, after those DBAs and programmers understood what I needed (my firm) in the realm of rigorous audit trails that were required, and had accepted the fact that a few bad apples in the corporate world screwed all of them...they then got over it and logged/documented/signed-off on/archived what they needed to in order to please audit commitees & the Big 4 and YET were still able to support the mission of their organization in a timely manner...and still keep the money they were earning. Still reading??? This stuff is money. I will give you their solution for those times that DBAs/programmers MUST go into the production environment to make things happen for users who screamed at the help desk, and finally were forwarded to the pros in the back office...It's brilliant and even my old Big 4 audit firm liked the solution on a global scale for that client... And now I won't even bill you for it... Ready??? It's called the "Break Glass Procedure". It's a formal solution, signed-off by the CIO, posted as an official corporate IT policy and empowers you to do what you gotta do NOW for the traders (in my past case). What you have to do: 1.) Make sure an automated log records the event. 2.) Make sure you get management approval later on (since 99% of you ain't criminals..nothing going on that ain't right and after all..you are trusted by management to do your damn job or you wouldn't still be there...We all hope). Just get the approval in writing/softcopy and keep it forever. 3.) Archive the approval for the external/internal auditor's pleasure. Archived email approvals may work, but formal change management archive apps are better...Depends on your firm's budget for such fancy stuff. My clients had the money. If you don't, save emails. Burn the shit on DVDs if you have to. Yes, it requires more time, etc... but it works, keeps the auditors off your butt and lets you get things done NOW so you can keep your job since the front office signs your checks. Again, I read some of the very legit concerns above and just have to say that MOST auditors want reasonable, formal plans and proof of compliance therein...The rest is billable conversation. For the good IT auditors and the wannabe techies alike...Give it to them and push back and defend accordingly. Challenge their definition of risk and your risk mitigation if they sweat Break Glass. One note...Break Glass is well-defended as long as you aren't doing it all the time (monthly at the very most in my investment banking audit experience...if it happens more often than your industry benchmarks...and you better know them...the development and testing groups have process problems and IT auditors will smell blood and open up on you about SDLC). Show that your initial SDLC clearly shows that rigorous pre-production rollout testing was performed (have that ready to present as well) and show that the documented production fix you did was an exception not forseen during such pre-rollout testing (or even if not)...and then show the auditors compliance to Break Glass and the happy audit trail therein... It's bulletproof unless you are dealing with a real ass. If you are dealing with Marvin the Audit Moron, push back and bump your defense up the chain. Afterall, either politics/inherent risk/profit still weigh heavily in pre-exist audit report content decision making reviews with the client. It's a reality...Verbal vs. Formal Finding. Package it to win. Lastly, if you have a formal change management process that can capture the live production change and approval, dump a brief summary of your actions in it. One of my investment banks did just that..For example:A production change was done over the weekend in the Tokyo time zone, and the New York (Global) head DBA manager (due to a silly reporting structure) reviewed and approved it 48 hours later and the security folks were even cc'd on the event. Why was this deemed good in my Big 4 firm's eyes? Because the process was recorded and showed management approval and security/audit review capability after the fact...and the big shots on both sides of the audit table still bought each other drinks at the end of the day (which still happens and which I don't have to see anymore). Hope that helps. Mista CIA, CISA, CISSP |
|
CISA
2006-05-31 |
re: <b>SARBANES-OXLEY SUCKS</b> Did you ask the auditor at D&T if the issue was that of access (a/k/a read only) or the ability to actually make changes to the production envrioment? Changes are the concern is that of segeration of duties and the ability to change data, tables, structure is the concern and you may be a ble to reach an agreement if you could prove your developers have read only on the production box, which would allow you to "see the problems" fix them in development and have someone else migrate them to production. |
|
CISA
2006-05-31 |
re: <b>SARBANES-OXLEY SUCKS</b> Did you ask the auditor at D&T if the issue was that of access (a/k/a read only) or the ability to actually make changes to the production envrioment? Changes are the concern is that of segeration of duties and the ability to change data, tables, structure is the concern and you may be a ble to reach an agreement if you could prove your developers have read only on the production box, which would allow you to "see the problems" fix them in development and have someone else migrate them to production. |
|
OXLEY
2006-06-15 |
re: <b>SARBANES-OXLEY SUCKS</b> Can anyone point me to these specific section i.e. access control who can and who can't in SARBANES-OXLEY? Thank you |