SarBox Lawsuit Could Rewrite IT Compliance Rules 124
dasButcher notes that the Supreme Court will hear arguments next week brought by a Nevada accounting firm that asserts the oversight board for the Sarbanes-Oxley Act is unconstitutional. If the plaintiffs are successful, it could force Congress to rewrite or abandon the law used by many companies to validate tech investments for security and compliance. "Many auditing firms have used [Sarbanes-Oxley Section] 404 as a lever for imposing stringent security technology requirements on publicly traded companies regulated by SOX and their business partners. SOX security compliance has proven effective for vendors and solution providers, as it forces regulated enterprises to spend billions of dollars on technology that, many times, doesn’t prevent security incidents but does make them compliant with the law."
Rule #1 of government.... (Score:2, Informative)
The primary purpose of every law passed has the creating 1 or more jobs, whether they are productive jobs or not.
SarBox? (Score:5, Informative)
I've seen SOX, but never SarBox. If you're going to CamelCase, do it right: SarbOx.
Re:Rule #1 of government.... (Score:4, Informative)
I'll field that one:
Unions are irrelevant.
sox isn't all about IT. (Score:2, Informative)
For example... per SOX, business documents and financial reports must be kept for 7 years. If you're documents and records just happen to be in digital format, then your are mandated to to have digital backup retention for 7 years...otherwise sox has nothing to do with your computers. SOX doesn't have enough meat on IT specific matters to be used as your sole baseline for IT requirements.
I don't think SOX needs to be rewritten or abandoned...we just need a different solution to solve the IT problems.
SOX and IT is Poorly Understood (Score:2, Informative)
I am a SOX IT auditor, so here are a few thoughts. Yes, I'm posting as an Anonymous Coward because I don't want my name tied to this in case someone from my firm sees this.
1. SOX is not about information security and security events. It's about determining if sufficient controls are present to prevent or detect material misstatement in the financial statements. For example, you have crappy network security. A hacker breaks in and steals customer information. While very damaging, there is no impact on the financial statements from a reporting standpoint (assuming that your accounting department properly books the entries for any fines and penalties - and this is assuming the hacker only copied data and didn't submit anything falsely). If a hacker did submit something falsely, the auditors would fall back on manual review controls, in the business processes (e.g., reconciliations) to try to identify anything major.
2. If your IT auditor's told you that to be SOX compliant you had to log everything, then you were told incorrectly. We only want to look at logs when we find major problems elsewhere, and we are only wanting to look at the logs to try to determine the level of risk associated with the issues we have identified. Logging of failed login attempts is useless, for SOX, since the account wasn't used (hence FAILED login attempts). Obviously, many of these things are good to look at for overall security, but they have no impact for SOX.
3. Here are the basics for IT SOX compliance:
a. Basic segregation of duties. The major problem here is that many companies let their developers have full access to production environments or let end users be system administrators.
b. Have a decent change management process. Again, don't let your developers have update access to the production environments. Make sure you keep documentation showing that changes are tested and approved. This doesn't have to be anything fancy.
c. Have a decent process to document new system implementations and major system upgrades. I can't begin to tell you how many times I've had clients implement new systems and give everyone full access just because it was easier or didn't check to see that they converted their data from the legacy application to the new application completely and accurately.
d. Have a process to follow-up on production processing errors / major events. If you have tons of job / batch processing abends and can't show that they were resolved in a timely manner, we can't be sure that transactions didn't get dropped.
Obviously, SOX can be very complex, especially if you have a very complex environment. However, if you actually read Section 404, there is nothing there that calls out specifics (i.e., like the specifics listed to be PCI compliant). It should be all about risk management.
Re:SarBox is always the excuse (Score:4, Informative)
How about rewriting the structure of the management as they clearly do not understand what 404 is all about?
404 doesn't tell you to do anything. It only ask you to show that you have internal controls and that they are deemed sufficient for a company of the type/size you're working for, and that you actually is following your controls. The auditors only task (related to 404) is to check that you do what you are saying and make a judgment on their observations.
Re:SOX is choking our companies, kill it. (Score:4, Informative)
I have worked for large companies in the past, and SOX is seriously undermining the ability to make changes, or indeed for rational process to take place in the daily operation of IT.
It's doing no such thing. People may be using it as an excuse to build an empire or do stupid things, but that's not the fault of SOX. I worked for a *VERY* large financial company (the overall IT budget, across all branches, businesses, etc, was measured in the *billions* of dollars), and not once were we stopped from doing anything because of SOX. Not once was it even an issue, either.
Put the blame where it belongs, on stupid people. Then fire them.
Re:SarBox is always the excuse (Score:3, Informative)
The sad fact is, it probably WOULD break SarBox compliance, it's frickin retarded.
Just about everything a company does relates to SarBox either directly or indirectly, so often an IT department will become terrified to make the smallest change to avoid inadvertantly breaking compliance, or making a change while staying compliance will require more money than the change is worth.
I.e. if you request a change to save $2000 a month in productivity losses, but maintaining the change will cost $4000 a month, it does not make sense to make the change. Period. SarBox has significantly raised the cost of even minor IT changes that have anything to do with private data (even indirectly).
Re:SarBox is always the excuse (Score:4, Informative)
404 doesn't tell you to do anything. It only ask you to show that you have internal controls and that they are deemed sufficient for a company of the type/size you're working for, and that you actually is following your controls.
That's the rub, and that's why this guy is suing. He owned a small accounting firm because, no matter what he did, the SarBox auditor's board determined what he was doing wasn't good enough, and the only changes they would accept would prevent him from turning a profit.
The SarBox board killed a legitimate business that was operating in good-faith compliance.
That's far, far too much power for a bunch of nameless beureaucrats.