Question

  Asked: Jul 27 2005   10:40 AM GMT
  Asked by: mstallings


module moves on i5


Auditing, Tech support, Networking, Application security, Exchange, Instant Messaging, Encryption, Database, secure coding, Security Program Management, Compliance, Risk management, CRM, Policies, Disaster Recovery, Development

I wanted to check on a possible solution for a problem we have run into with our module moves. Cause of audit requirements we can't have pgmr's in the productions systems. So as a work around I have them creating their code in sourclib on the test partition then I have operations copying it into a production library on the test partition then moving it to the production system. I went that route because auditors said that the programmers couldn't compile their own code because they thought they could hide some source. My question is this the best way to handle this move? Is there a cleaner way?

Subscribe to Alerts! Get questions and answers delivered to your Inbox.


E-mail me updates on this question



   SUBSCRIBE

hidden modal window

Answer Wiki (Improve, edit or add to this answer)


 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0



What you need to do (by the letter and spirit) is to get into what is called "Release Engineering" or "Release Administration".

What it amounts to is isolation of the programmers from the production systems - with controls to make sure that what the programmers wrote is what you're duplicating.

The key steps involved here are:

Archival of changes (RCS, VCS) in a verifiable manner - There are both commercial and "free" versions of source code version/revision control systems.

The programmers can compile their own code - simply because they need to make sure that it does what they intended - but - then they submit all source code, make files, etc. to the RA/RE folks who essentially clone the programmer's development environment, and then compare their binary output to what the programmer submitted.

This covers not only the possibility of "hidden" source code, but also the more likely and common omissions of a forgotten header file, compiler upgrade or other trivial error that might result in the final product not being what the programmer intended.

Properly done, this also covers the organization from the "hit by a bus" or disgruntled employee scenario.

On a slightly humorous note - there's a cartoon that shows a widow weeping over a gravesite, and a man speaking to her saying "I know this is a difficult time, but did he ever say anything about source code?"

Hope that helps,

Bob
  • AddThis Social Bookmark Button

Browse more Questions and Answers on Security, Microsoft Windows and Networking.

Looking for relevant Security Whitepapers? Visit the SearchSecurity.com Research Library.


Discuss This Answer


You must be logged-in to discuss a question. Log-in/Register

MilesButler  |   Jul 28 2005  5:11AM GMT

You need a Change Management Product.
We use MKS Implementer.
<a href="http://www.mks.com/products/implementer" rel="nofollow">http://www.mks.com/products/implementer</a>

I hasten to add that this product serves our purposes on the iSeries, you will need to undertake your own assessment.
Miles

 

iceprincess  |   Aug 3 2005  8:17AM GMT

We also use MKS Implementer. Our developers do not have authority on production systems to perform any changes. They create and test on a development system which is set up to transfer the program changes to production. Production Control actually moves the code from dev to prod.

On a separate note, for after-hour emergency needs we have created an ID called “emergency” which allows the developers to perform the required changes after they have provided required information (trouble ticket, etc.). We have the ID set up so that it automatically becomes disabled immediately after the log in and the ID must be reset for each use. We also use journaling which captures all log information for auditing purposes.