SOX Compliance Nightmares

[Dave La Mar]

As many of you know many businesses are struggling meeting Sarbanes-Oxley
compliance and still be able to run their respective business.
As ridiculous as many of the requirements for compliance are, we are
compelled to meet them.

We currently have an audit firm assisting us with meeting SOX compliance.
One of the high points of concern is developer access to out production
HP-UX boxes.

Some background:
1. We are a small shop with less than 20 developers.
2. The developers have logins to the production boxes, but their login
forces them into an su - to a generic user.
3. Both the generic user and the developers are not allowed direct logins.
4. All activity of the developer once su'd is recorded and reported daily.
i.e. All activity from the history file is segregated by developer with
times and commands issued.
5. All work done by the developers involves korn shell scripts, some of
which execute SQL statements against an Oracle database(s). Each script
writes out to a log file.
6. The actual execution of the korn shell scripts is handled by a third
party scheduling product.
7. Should the scheduler note an error in execution, the developers need to
access the log file in order to resolve the problem.

What the auditing firm is adamant about is that no developer has access to the
production box.

Just how are some of you coping with not allowing access, but still supporting
your servers for processes written by and supported by a development team?


Any suggestions?

dl

[Patrick Wallek · Accepted solution]

SOX is one of the biggest pieces of B.S. legislation that has evern come down......

Anyway, I won't get started down that road.

We have had good luck with auditors by thoroughly documenting things that the auditors have concerns about.

Your procedures sound VERY VERY good and very thorough. I'm not sure why the auditors would have such a problem.

The first thing I would ask is WHY they are so adament. If they say because of SOX, ask them to show you specific area of the SOX act that pertains to your situation.

[Doug O'Leary]

Hey;

In a perfect world, the auditor is correct; however, it seems you have some pretty good policies and procedures in place to protect production environment.

At any time during this process, your company is allowed to accept the risk associated with a given weakness. What you then end up having to do is document that you understand the risk, accept it, and what you've done to reduce that risk.

The auditors should have a procedure for doing this. If they don't, toss them out on their ear as they're not worth the probably exhorbitant fee they're charging.

HTH;

Doug

[Doug O'Leary]

Hey;

To follow up on P.Walleck's post, he is correct that these requirements can be fought. One issue that I wrestled with a client company was the auditors' demand that all umasks be set to 077. That pretty much broke the applications - go figure.

I asked them to show me the source requirement. They never could so that particular item magically went away...

All that being said, the one good thing about SOX is that it's hopefully getting companies a little more security conscious. I worked at another significantly sized client in the financial district that had root level trust relationships, root crons running out of unprotected directories, etc, etc. Getting that area cleaned up took awhile, but would probably have been impossible without the SOX legislation breathing down management's neck...

Doug

[Rick Garland]

The auditors can express their concerns but if you have the documentation, a business case, and an audit trail of what was done by who and when, this is what the auditors should be looking for.

The auditors are not there to tell you how to run the business, but to find out if you know 'why' you are doing the the things you are doing.

If you have a developed set of policies and procedures with accountability, you have pretty much met the goal from your standpoint.

[Dave La Mar]

Great replies! I knew it couldn't be just a case of obstinence by me.
I will be using many of the suggestions especially the "show me" ones.

Thanks and keep them comming, as I am loading up my ammo box.

All points will be assigned when I close this thread.

Thanks again.
-dl

[A. Clay Stephenson]

One technical fix would be to have the scheduler copy the log file to the deveopment server when a non-zero exit code is detected. That way the developer would not need direct access to production. In general, the way your problem is solved in the SOX environment is to have the developers deposit their fixes and patches and new code in a repository (which could simply be a directory on the development box) or better still a 3rd box. Another person with access only to the repository and the production environment actually installs the software. Using this model there is a clear (if dumb) division of labor and clearly auditable paths of deployment. This does not necessarily involve more people. For example, a developer might have access to certain areas on the development box but be responsible for production deployment in other unrelated areas.

If you actually read the Sarbannes-Oxley act the IT related sections are extremely vague.

[Zigor Buruaga]

Hi,

I recently passed my second SOX audit ... and nightmare is the perfect word for this, for sure.
My suggestions:
- If possible, send a mail to the developers with the log files they would need attached. That will help you to provide an evidence on that the developers don't need access to production boxes to check their jobs, and that you/they take care of the monitorisation of those jobs.
- As mentioned by Mr. Stephenson, if possible try that your developers deposit new programs out of the production servers. They should be able to test their programs on a similar/identical test environment, but I think they are not allowed to put them in production.
- In general terms, you are a "trusted" person, but the developers not ( don't want to offend anybody ;-) ). They should not have access to productive data. If they should have accesss to the productive server ( document the business reason and get approval from your client for that ), be sure that they do not have access to the productive data ( check unix permissions, database access, etc ). In case they still need the access, try to establish a procedure to control that access. For example, if they ocasionally need it, don't give them any privilege, only warn them that they should call you whenever they need such access, so you will go to enter the required user & passwd while sitting with them to control what they do ( let's say it's some sort of "manual" sudo ). OK, it's very simple example.
- Be sure that the escalation between you and your developers is well documented too.


Regards,
Zigor

[Steve Lewis]

We created an extract-o-tron program that extracts particular groups of records out of production, into separate datafix databases for support to fiddle with, then the required fix is put into our CM system for promotion back into production upon sign-off by the operation's representative. It prevents production support from directly updating production without sign-off.

We also have an automatic email of log files out of non-zero return code batch programs, to production support.

Root access is a real issue - we had to enable trusted, audit and a syslog server to which the UNIX sysadmin has no access.

But, these measures aside, you will ALWAYS need an emergency change procedure.

[Yogeeraj_1]

hi,

allow me to add this comment...

Though not being in the US, we are also forced to ensure that we have similar policies and procedures. In fact, our US clients are insisting that we have such an infrastructure so that we can trade together.

I believe that with time this compliance will become sort of a global standard...

good luck
kind regards
yogeeraj

[Dave La Mar]

Again, some great replies.
On the automated emails-
These are in place upon script failure. Unfortunately, the information in the email may require further investigation elsewhere in another directory or in the actual db. Likewise, access to email may not always be available as we are routing them to Outlook accounts.

On where any script changes are to be made -

1. We do have a duplicate development environment for the purpose of testing changes.
2. Not all "access needs" require a simple read of the email or tweak of a script.
3. We do have a procedure in place for moving script changes to production.

From what I am reading, I am coming to the conclusion that:
1. We may meet compliance with the login tracking.
2. We could institute a login procedure where the Operations area has control over a single user generic login, provide the password in an emergency, and change it following the user log out. (But this obviously violates some audit firm's interpretations.)

As some have pointed out, the Act is extremely vague. From that, I have printed off the Act in it's entirety and will have it in hand in order to pass it to the auditor and say "Show me where this is written."

I have also noted from the posts, each auditing firm appears to be following no set lines of audit and are expressing interpretations accordingly. (No surprise here as I have see both duplicate and new questions each year over the last 25+ years.)
The one commonality among them is "most often they have no idea what they are asking and have never worked in the real world."

Thanks for all the input.
Others that may have more to add please do so as I will probably not close this out until day end.

Again, thanks for the quality posts.

-dl

[Dave La Mar]

Doug -
Just a note, as I was assigning points, I was not indicating your replies were worht less than others. Just attempting to be fair in point assignments to all of a total of 9.
Thus with your two points assignments.

And again thanks for the input and the support of the frustration we are all going through on this.

Best regards,

-dl