SarBox Lawsuit Could Rewrite IT Compliance Rules
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."
I tried to look up this 404 thing, but I couldn't find it anywhere.
Well at least now they'll spend all that money on making sure things are actually secure!
How about rewriting the law so that every request to my IT department doesn't result in "This functionality would break SarBox compliance", regardless of how related to SarBox the request actually is?
I was never able to find that section, kept returning a "not found" error or something.
The primary purpose of every law passed has the creating 1 or more jobs, whether they are productive jobs or not.
-- Many men would appreciate a woman's mind more if they could fondle it
I've seen SOX, but never SarBox. If you're going to CamelCase, do it right: SarbOx.
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.
SOX was meant to prevent another ENRON, but those things will happen regardless of rules - look at the collapse of organizations like FannieMae, well after SOX was in place. Instead we are harming all large businesses just to prevent a one-off case that we are not really preventing anyway!
Kill SOX and let companies get back to what they do best, instead of spending a lot of time simply deciding what compliance means and using the rules to build (even more) fiefdoms within giant companies.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In order to ensure security against DOS attacks, I think it would be reasonable to mandate that all vendors be required to prove that their programs will halt in finite time, given an arbitrary input.
That seems like a wholly reasonable request, not too burdensome, and should improve security.
I inherited a bunch of apps that had atrocious logging practices. They were inter-twined and when a problem arose, it was very difficult to PD. Management didn't care to spend money adding some log statements, it was good enough. SOX forced us to place logging statements at system boundries. This wasn't a complete logging overhaul but it really did help with future PD.
Blar.
From TFA "Now, here’s where things get interesting. Beckstead decided to sue PCOAB not over the deficiencies found, but rather the oversight board’s very right to existence." ...
As a disclaimer I have to say I have worked for Financials IT for quite a while and SOX was quite literally the bane of our existence for over 3 years. Whether SOX is a true measure of compliance is still an open question on my mind
The implication here is that if the Justices do rule in favor of Beckstead, what does that say about other government organizations that "audit" citizen's affairs?
In other words, you are told that all your servers must be 1U, you know this for a long time and make an effort to make sure every server is 1U, you go as far as dedicating an entire year in ensuring that servers must be 1U, then you get audited and they happen to find that 4U box your support guys used to launch all that crap that no other box was capable of handling, simultaneously, so you fail that portion of the audit.
You just SUE the people who enforce these efforts in the hopes that the very laws you knew about and made a concise effort to abide to get disregarded or amended in the course of a hearing? that's it?
Are you using 1U just as an example or are there really rules somewhere about using only 1U's, and not 4U ?
Stephan
http://stephan.sugarmotor.org
SOX compliance itself has more to do with accounting practices than it does with IT. IT related affairs only come into play when it goes hand in hand with the accounting/financial requirements. If you are relying entirely on SOX compliance laws and regulations to fulfill IT requirements and security standards, you are ill-prepared for IT compliance.
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.
Shh, Adolph, Shh They think you are dead.
Nitpicky, I know, but the title of the Slashdot article (not the underlying article) uses "SarBox", as if it were some brand name for a kind of box.
It's the "Sarbanes-Oxley" Act, sometimes "Sarbox" or "SARBOX" (for those who feel compelled to treat every new word they don't know as an initialism) but "SarBox" is right out.
"SOx" or "SOX" are much more common.
Who refers to Sarbanes Oxley asn SarBox? I've only ever heard of it as "SOX." I can't imagine why the "b" would be stressed, anyway.
I know this is the internet, but we really shouldn't just go around inventing acronyms for headlines.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I've worked in companies where SOX was used to make processes more stringent and intelligent. And I work in a company where SOX has allowed the accounting/finance department to dictate all manner of corporate and IT policy.
Yes it is POSSIBLE to have rational adherence to SOX. But that seems far rather the exception than the rule.
In order to survive SOX, companies need keen leadership -- one that will prevent the sort of "SOX run amok" mentality and provide solid guidance to the company as a whole.
The problem is that even if they do succeed at that, it's a huge drain to provide truly effective leadership - and all that energy and manpower that goes into smart adherence to a loose standard, could have gone instead into leadership in product development or marketing or anything that actually provided an iota of real value to the world.
Step back and think about the big picture, do we really want brilliant leaders across the nation focused simply on regulatory compliance? What a waste of human potential!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I agree with the article: it is something that auditing firms are using to scare the bejeesus out of everyone at the C-level.
It slows companies down in myriad ways. Without preventing another Enron. Evil people will do what evil people do, and SOX aint gonna stop them.
One other way it is abused: internal IT stonewalling. Now our IT group has an easy deflection for any new project: SOX. it's like a bell rings when the say it, straight out of groucho marx. I've given up even trying to fight. When they play the SOX card, I just leave the room. There's no winning the argument.
We need a good Article 10 fight. Now.
Washington is out of control, and has been for a while. As good a time as any to make a stand.
deleting the extra space after periods so i can stay relevant, yeah.
Problem Determination?
Blar.
The National Fire Protection Association is another organization independent of the executive or legislative branches which has been granted legal authority to specify how you may wire a building, including your own house.
NFPA 70, aka the National Electrical Code http://en.wikipedia.org/wiki/National_Electrical_Code, "is commonly mandated by state or local law".
And did you miss all the outraged slashdot discussions spurred by private organizations claiming copyright over specifice state and local laws?
I want to know so I can never do business which such a shoddy shop. My company has strict SOD and we enforce it through tooling. We have three groups: Development, Test, Operations. I'm on development side so I check builds and docs into the source code control system. Test pulls it out, applies it to the test environment, runs tests. Test then passes the code and documentation to operations who updates any configuration parameters that differ between test and production systems and installs it with the rest of us standing by on a chat in case anything goes wrong.
Blar.
The IT department will simply come up with another excuse. The preventers of information services are quite adaptable. When you ask for something that the blessed vendors are good at (or requires actual work), the response is the excuse-du-jour. SarBox is popular, but there are many others.