Manage Learn to apply best practices and optimize your operations.

Keeping programmers honest -- part 1

If you are like most iSeries security officers, you probably cut your teeth in the IT field by doing some programming. It might even be that you still get involved in programming and your role as security officer is a part-time role. So, you have an appreciation of the special problem that programmers pose for system security in your environment. This article takes a look at that issue and offers some suggestions.


Rich Loeber
If you are like most iSeries security officers, you probably cut your teeth in the IT field by doing some programming. It might even be that you still get involved in programming and your role as security officer is a part-time role. So, you have an appreciation of the special problem that programmers pose for system security in your environment. This article takes a look at that issue and offers some suggestions.

More Information

The problems are many. First, programmers know how things are handled internally in your systems and know how to get around in the system. If programmers want to get at some secured information, they probably have the know-how to do it. Secondly, programmers have a regular need to access all of the data on your system in their testing role during project implementation. Lastly, programmers tend to see security as a hindrance to getting their work done. (I once knew a programmer who knew OS internals on a S370 I was working on and found a trick he could use to submit his program compiles so they would always go to the head of the line in the compilation job queue. No one could figure out how he was getting so many compiles done while everyone else had to sit around and wait.)

Your responsibility as security officer is to create an environment for programmers that is secure yet lets them get their important work done effectively. These are not always compatible goals. Here are some ideas you can consider:

  • Even though they will tell you they need it, do not grant all special authorities to your programmers. Give them only special authorities they need to get their work done. A security officer profile should be the only one to have *ALLOBJ authority.


  • Set your programmers up in a group, but don't associate them with the special QPGMR profile provided by IBM as that has some special qualities you don't want associated with your programmers.


  • Don't let your programmers have direct access to your production libraries. Set up test libraries and control the distribution of live data into those test libraries.


  • To create test data, set up a special copy program that adopts the necessary authority to create copies of production files in your test environment. Monitor the use of that program, including maintaining an internal log of when it is used and by whom.


  • Programmers often, like my friend from years ago, like to get their compiles right away by running them interactively. That can wreak havoc on your system performance. Consider changing the compile commands so they will only run in batch. Also, set up your programmers so they default to the QPGMR subsystem and make sure it is set to priority 30 so they aren't stealing valuable CPU cycles from your production environment. Consider restricting access to the CHGJOB command.


  • When you move an application from testing into production, review all of the data and program objects to make sure programmer ownership has been removed and the objects are now all owned by a profile that will be used to control production access.


  • Keep a separate set of source files for program source that is being worked on. Do not give your programmers open access to the production version of the source code for a program they need to work on. Move the source in and out of test mode in a controlled way and log when source members are moved in either direction. You can do that from a special program that adopts the necessary authority to make the source member moves and logs use activity.


  • Don't let your programmers have passwords that don't expire. Every programmer I've ever met has a favorite password that they like to keep. Don't let them get away with that practice. If you programmers don't practice good password controls, how can you expect your end users to take security seriously.


  • This list just scratches the surface. If you have more ideas in this area, let me know so I can share them in a future tip. You can reach me at rich@kisco.com. All e-mail messages will be answered.

    ---------------------------
    About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.


    Dig Deeper on iSeries system and application security

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.

    -ADS BY GOOGLE

    SearchDataCenter

    Close