Advise on Internal Control Policies

This is almost a case study.  This is a relatively small
shop with about 10 people in the entire IT which includes
three managers, three development IT, 1 security, two
sysadmins and one assistant admin, 1 tester, 1 mgr who
really isn't IT and only does one small administrative job
concerning IT.

I am in need of some basic advice on establishing an
internal controls policy.  I'm aware of what is required but
I feel like I'm swimming upstream.

Mgmt has decided to utilize bugzilla, rdist and cvs to
establish the internal controls procedure for our code
modification (development phase), testing (phase) and
production (phase).

The problem started due to an IT audit which indicated we
didn't have any policy or regulatory requirements, (which is
true).  Our shop generates  nice hundred mill in revenues
annually.

The computer room is open to eight of the ten same IT
people, this does not include security. These same people
have direct (root) access to all the boxes remotely
(including VPN) and the computer room.  In the past they fix
problems as they occur.  No procedure no controls.  Our
company is service based and bills through the web.

The computer room has motion sensor video which is reviewed
by the two sysadmins.

At any time any one of these eight people who have direct
access to the code, the os, the data and the hardware can
change the web interface to divert payments to an anonymous
bank account over the weekend, come in Monday and remove the
billing from the database while it gets reconciled and add
it back afterwards.

I'm not saying they do this I'm just saying that it can be
done with ease since they have access to all this
information.  My problem is that by using bugzilla as our
internal control procedure they have mixed interpretations
over what is bugzilla.  Although they would like to use it
as the IC procedure they also only would like to use it for
reporting bugs only, hence the name bugzilla.

But when I try to figure out how bugzilla along with cvs and
rdist are going to provide us with a method they insist that
it will take care of the SDLC (system dev life cycle).

I've suggested third party software to do this only because
it would establish a control for data integrity.  If we
control the controls then we can manipulate the end result,
using bugzilla I feel the data could not be relied upon.

and assistance, comment or criticisms would be helpful.

It appears you are trying to solve a problem with software
that really
should be solved with policy, procedures, and standards. 
You can throw
as many packages as you want at the problem, but if you
don't get basic
rules in place you will have the same problem.

Without in-depth knowledge about the environment these
suggestions may
not be valid, but hopefully they can provide some
assistance.

1st: Determine exactly what needs to be protected or
resolved from an
audit standpoint.  (Do you know all of your vulnerabilities
and what
should be protected 1st?)

2nd: Identify the roles and responsibilities for each
individual and
list any gaps (Your org appears to have some money, so maybe
increased
head count will help solve the overlap of responsibility.)

3rd: Create written policies that are realistic to implement
in the next
6 months to year.  Most auditors / assessors are simply
looking for
documents.  Once documents are written they typically assess
against the
documents or some framework.

4th: Implement the policy and controls.  

In some cases if management doesn't want to listen you may
have to bring
in an outside service to relay the message.  This is all
high level, but
if you don't separate the functions of the staff and their
access you
will continually have audit issues.  

Removing development access from a production operating
system doesn't
require any additional tools.  Using an application to try
to control
that access other then locking them out of production
entirely may not
work.  Many applications such as webMethods have command
line prompts
that could allow them to gain system access anyway if you
have not
created and implemented appropriate hardening standards.

Stick to the basics! Don't throw products at the problem.

Hope this helps!


Jason Bevis