Securing Your Programmers

By Rich Loeber

If you are like most IBM i 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 will take a look at this issue and offer some suggestions.

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 a programmers wants to get at some secured information, they probably have the knowhow 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. Nobody 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. Only give them the special authorities that they need to get their work done. Nobody except a security officer profile should 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 that 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 these 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. This can wreak havoc on your system performance. Consider changing the compile commands so that they will only run in batch. Also, set up your programmers so that they default to the QPGMR subsystem and make sure that it is set to priority 30 so they aren't stealing valuable CPU cycles from your production environment. Consider restrict 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 that programmer ownership has been removed and that 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 this 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 just 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 this seriously.
• If a programmer insists on *ALLOBJ and can make their case, consider adding security to their user profile by requiring a 2 Factor Authentication (2FA) logon protocol. If you need a 2FA solution, take a look at Kisco's i2Pass product.
• Since IBM i OS 6.1, you can host a client LPAR on your system fairly easily. Using this capability, you can create a separate partition on your system where the programmers can have full access while still restricting access in your production environment. You can find an IBM document on how to set that up HERE. If you are using data from the production environment for testing in your programmer's partition, you will still need to guard the data. But, if you only work with test data, then this is a good solution for you.

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 at kisco.com, I'll try to answer your questions. All email messages will be answered.