Fog Creek Software
Discussion Board




Sabanes-Oxley?

Sbanes-Oxley is a bit of legistlature designed to prevent enrons and worldcoms.

It requires CXO officers to sign that the income and balance sheets on the financials are correct - and holds them liable for that correctness.  It also requires very strict internal controls, IE:  One person handles the money, someone else behind a wall counts the money to make sure it's "Right."  This prevents fraud.

Now they are saying that this needs to go to the IS Shop - one person needs to modify the code, another puts in into production, to prevent hackers and fraud.  Developers can't have access to production.

And it streches farther.  My company is a key supplier to publicly-traded companies.  We aren't publicly traded, but the CXO of a publicly traded company is certifiying that the numbers are correct, so they are requiring _us_ to be auidited and certified, and to have these change control procedures in place.

I've looked at all the IS Success Literature, and I just can't find a real IS expert saying that this stuff is required.  It's all accountants who are extending thier analogy to the IS Shop.  Oh, and Accounting FIRMS who are insisting on this.  Oh, wait, that's how they get paid.

Something seems wrong about all this.  Does anyone have any experience with Sabanes-Oxley in the IS Shop, or what ceritifcation _should_ mean for a supplier or a Sarbanes-Oxley required shop?

thoughts?

Anon this time
Monday, August 02, 2004

Having all code reviewed before moving into production doesn't sound like such a bad idea.  It's all in the implementation.

Lou
Monday, August 02, 2004


It's not that it's reviewed, it's that developers won't even have _access_ to move the code to production.

You need to have a separate and distinct unit where all they do is move code to production.  I _guess_ they have to review the code as well, to make sure it's "Good."

so they have to know every language in the shop.

Now you're starting to talk about a large team ...

Anon this time
Monday, August 02, 2004

It's not that it's reviewed, it's that developers won't even have _access_ to move the code to production.

You need to have a separate and distinct unit where all they do is move code to production.  I _guess_ they have to review the code as well, to make sure it's "Good."

*******

This is actually a recommended practice. Developers move code from development to test, and QA/sysadmins move code from test to production. They don't have to really know the code; they just follow the deployment directions given by the developer.

If one person moves code from dev->test and test->production, then bug-causing myopia never gets a second set of eyes.

Philo

Philo
Monday, August 02, 2004

Most corporations will state that developers don't have direct access to production, and most have written procedures which confirm this.  But in practice, it hardly ever happens.

Personally, I think it's a Good Thing (tm) for programmers not to have direct access to put their code into production.  Not because I don't think programmers in general are incompetent, just all the other programmers *I* work with.  :P

muppet
Monday, August 02, 2004

When I worked for a big financial (in the UK) this was all standard practice.  Developers could take the code to a pre-release stage, but couldn't put it into production.  A separate team would always control moving development systems to production.

It sounds restrictive, but in fact the 'production' team often found real no brainer mistakes and since all promotion to production status went throught them they could schedule implementations of various related systems while minimising risk.

This can of course only work if the dev teams have test environments that 'exactly' mirror the production systems - as long as that is the case the extra layer can only help prevent the developer making a fool of themselves (or deliberatley breaking things).  I always thought it was a good element in the CMS to have people that had no agenda when it came to implementing systems.

anonymouse
Monday, August 02, 2004

Back in 1971/1972, there was a company called Equity Funding Corporation of America (EFCA). At that time, the Big8 all had their own individual auditing procedures, and everything was totally proprietary. Also, the only consulting company that would have been capable of auditing "computers" at that time was IBM.

EFCA used their their computer system to fake sales of their product (insurance). They made a rather elaborate scheme to stick it to Wall Street, to kite up their stock prices. As a result of the scandal (and the several hundred millions of dollars lost),  the Financial Accounting Standards Board was created. In short, that was the Enron and SOX of that generation. There was even a movie made about it. The funniest scene was at the end when the cops raided the computer room with guns drawn, and they guys in horn-rim glasses sitting at keypunch machines looking up at them, while the cops look frantically for "the bad guys."

I believe that the company you are dealing with is afraid of getting stuck in the same boat again. I think they are also trying to get some sort of ISO type standards in place.

The procedure you are describing is similar to what happens in a bank. You don't let one person touch all the bits/bucks, and you have folks checking everyone, and checkers for the checkers. Moving code into production (from qa) or moving it from dev to qa is usually well documented and highly structured. If the code moved from dev to qa doesn't work, the developers can't touch it, they have to roll stuff back in qa and supply the "release engineer" with something that works. I've worked at some non-banks that also had structured releases like this also. It helps because it is common for some step to get left out of the documentation, and the person who moved it to qa did that step to "fix it" and then forgot to update the documentation.

Some places I have worked at, let the developers directly access "live" or "production" data, but some restricted access tightly, and munged up information that could otherwise be used by a less-than-honest developer to engage in lots of identity theft. Like what happened with Acxiom, where one or more insiders downloaded several gigiabytes of data to sell to others (perhaps your name, credit history, ssn and credit card numbers were among the ones downloaded and sold). I'm sure you can find other cases in the news where some insider was selling private information. It is my opinion that those sort of things will only get worse.

If I read your narrative correctly, I think you may as well look into ISO9000 certification. In civil/chemical engineering, a licensed Professional Engineer has to sign off on blueprints. Perhaps they are going to be wanting some sort of certified/licensed person to sign off on the code? Perhaps the developers will need to take 4-8 week absences from coding while the stuff they do/did gets audited, like other folks in a bank? Embezzlers and diddlers tend to get caught out when they have to take breaks, since they usually have to juggle things continually to keep the books balanced.

Here is a fun book that may give you some insight on what has happened elsewhere, and may happen again :
http://www.amazon.com/exec/obidos/tg/detail/-/0471269948/
(it is a quick read, so it won't take all weekend to read).

It is possible that I am reading too much into what you said.

Peter
Monday, August 02, 2004

I'm sorry Peter, your post began "Back in 1971/72" and then ran on for 6 paragraphs.  I took this as a sign that it's a long preachy lecture by an old fart, and discounted it entirely without reading it.

Just thought I'd provide you this useful feedback!

muppet
Monday, August 02, 2004

BTW, to make this kind of thing work, you have to have QA and sysadmins who are
- smart, and
- get things done

People who want to learn some itty-bitty niche of knowledge and spend the rest of the day whining that this, that, or the other is "not their job" will ultimately break the system - developers will get frustrated, and at some point the production passwords will end up with the devs, who do all the work.

The QA and sysadmins have to be willing to learn the myriad details involved in moving a system to production; QA need to learn a little sysadmining; sysadmins have to learn a little dev, etc.

Philo

Philo
Monday, August 02, 2004

Philo -

You've just described why this system does not work in 99.9% of everywhere.

People are willfully ignorant, greedy, complacent little buggers.  That's life.

Most folks who are smart and get things done go too far that end of the spectrum and make their job their life.  This is undesirable for other reasons.

I see very little in between.  In fact, people in the middle of this spectrum seem to have a rough time holding down jobs, for some reason.  If you're just enough of a go-getter to get the attention of management but not enough of a go-getter to work nights and weekends every week, then you're somehow worse than the folks who sit around quietly doing their mundane jobs with little or no initiative.

Anyway.. now I'm OT.

muppet
Monday, August 02, 2004

Public execution of the people that did Enron et al would have been VERY preventative of future infractions and would have saved us all from Sarbox.

Formerly someone else
Monday, August 02, 2004

Yeah sure, but if we do that, then we'll have to publicly execute most Republicans and Democrats, too.  Then where will we be?  At the mercy of the Libertarians?  How scary.

muppet
Monday, August 02, 2004

Sorry muppet, I need more coffee.

Peter
Monday, August 02, 2004

the S/O stuff doesn't seem that bad yet, we got checked by them, and they turned up stuff that's pretty obvious IT-wise, i.e. check permissions & passwords, etc.  Pretty obvious, but sometimes managers need a reminder that yes, "password" is a bad password, and by bad we mean someone is GOING to STEAL your STUFF!

sir_flexalot
Monday, August 02, 2004

> one person needs to modify the code, another puts in
> into production, to prevent hackers and fraud.
> Developers can't have access to production.

This is a common practice when the code operates with confidential data. Developers are not allowed access to the production in order not to have access to the data. Makes some bugs really fun to reproduce and fix.

www.alexlechuck.com
Monday, August 02, 2004

>  At the mercy of the Libertarians? 

Sounds good to me. 

I take fiscally conservative, and morally liberal over what we've got now.

christopher (baus.net)
Monday, August 02, 2004

I don't see the big deal re: developer access to production.  I can't see why developers would have more than read-only access to production systems under normal circumstances, anyway.

Rodger Donaldson
Monday, August 02, 2004

Yes, having to submit TPS reports in triplicate -- with the new cover letter -- to meet onerous requirements imposed by an outside consulting company that is incented to make outrageous interpretations of vague guidelines is definitely what's happening with Sorbanes-Oxley.

That said, implementing improved IT management and deployment practices is always a good thing. If SOX drives some maturity in the organization then more power to it. If it results in more levels of beuracracy and doubling or tripling the time it takes to complete projects then it will only result in overhead and exceptions.

When E&Y comes to give a presentation to your management, start updating your resume'.

IhateSOX
Tuesday, August 03, 2004

*  Recent Topics

*  Fog Creek Home