 |
|
| iSeries 400 Tips: |
|
|
|
ISERIES SECURITY TIPS
Keeping programmers honest -- part 1
Rich Loeber
01.18.2006
Rating: -3.64- (out of 5)
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.
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.
|
|
Rate this Tip
|
To rate tips, you must be a member of Search400.com.
Register now
to start rating these tips. Log in if you are already a member.
|
Submit a Tip
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
|
|
|
| TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of . |
|
| | |
All Rights Reserved, , TechTarget |
|
|
|
|
|
