Slashdot Mirror
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.
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?
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
And to do that, they'll need a definition of "secure". One that everyone can agree on. A standard definition, on might say. And to ensure everyone who says they're secure actual is, it might be a good idea to draft a formal document that explicitly lays out those standards, as well as methods for one company to ensure another company meets those standards. Heck, if it's that important, it might be worth thinking about turning that document into a law...
UTF-8: There and Back Again
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.
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.
Not if the fines scale in relation to the amount of information that was lost, and compensatory damages are included requiring payment of the estimated damages for each individual person's data loss (not an average spread to everyone). Of course the individual data evaluations must be done by a firm chosen by the courts, and paid in full by company that lost the data.
It's pretty easy to structure the law such that almost any company will be bankrupted by failing to secure data. That would also be silly, because no company can guarantee that no data will ever be stolen, so if you place the requirements too heavily on the fact that the data went missing, and disregard the amount of effort the company put into keeping the data safe, you could be destroying companies that do not desearve to be destroyed.
Generally, the best way to handle these things is to keep the language of the law vague enough that it can be decided on a case by case basis - i.e. the company did their best to protect their data, and so should recieve little or no punishment.
SarBox is the worst possible solution - it mandates security measures that are ineffective (because in the real world, the mandated measures were obsolete after a few months time) that are expensive to impliment and yield little or no added security.
One visible example is banking - you now have an image tied to your account login to prevent phishing. However, most people don't pay too much attention to it, and wouldn't care if it were different. Or, they'll use it that one time, it doesn't work like it is supposed to (because it's actually at a phishing site), they try again later and now it works (because it is now actualy at the bank website). Since it works, it must have just been some minor hiccup, and all is right with the world. Right? No, they just got their account access stolen, and if a person is smart they'll slowly siphon the money off instead of withdrawing large chunks of cash.
It's also easy to harass someone now, because of the strict regulations if you manage to find someone's account (or at a big bank, just randomly choose numbers) but can't access it, just plug a bunch of gibberish in a few times and they don't have access to their own money. That can be devastating, and it's untraceable if the harasser is using a public terminal.
SarBox aught to have been more vague, and focused on the good faith effort to secure a client's data. People get into trouble when they aren't handling data using the industry's best practices that way, for if the institution never bothered to check what the latest best practices were, they obviously weren't too interested in data security.
Setting it up that way, instead of with complex rules and regulations, give it the flexibility to adapt and apply to each situation, and there is no risk of it ever going obsolete, unlike the current SarBox law.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
One visible example is banking
My banking site decided that 2 factor auth meant that I had to type my info into a flash widget that analyses the typing style - I sort of doubt this is even half a factor. The CC sites I use demand I have 2 passwords - 1.1 factor auth. Basically, I'm saying that it's crap.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
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.
And you get "Flame Wrong Orgy", which, strangely, doesn't seem all that unusual on Slashdot.
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.
Exactly.
Really, two factor authentication only offers meager protection from a subset of attacks, yet I can tell you that implimenting it at each company was probably a $50k project, or, for the less efficient companies, a $200k project.
ROI for Sar-Box is shit. We've got a hell of a lot more expenses for a teeny bit more security.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller