Home > AS/400 Tips > iSeries security tips > Keeping programmers honest -- Part 2

	iSeries 400 Tips:	EMAIL THIS

	TIPS & NEWSLETTERS TOPICS

	ISERIES SECURITY TIPS Keeping programmers honest -- Part 2 Rich Loeber 02.06.2006 Rating: -3.50- (out of 5) iSeries news and advice Digg This!     StumbleUpon     Del.icio.us    [TABLE] In my last tip, I got a lot of good feedback from readers with additional ideas that help address the issue of access controls over your programming staff. Remember, the objective is to empower your programmers to do what they need to do without giving them the ability to damage your production data -- either intentionally or unintentionally. After all, programmers are human and can make mistakes. The unfortunate part is that sometimes when a programmer makes a mistake, it's a whopper. (I should confess here that I once deleted my company's customer master file by mistake. Fortunately, it was during off hours and I realized my goof right away and was able to recover the data before anybody found out about it. I was late for dinner that night!) [TABLE]			[IMAGE]

One reader described a situation where he keep the programmers separate from the production environment by keeping them on their own system. That is a great idea and not very hard to do in these days of high-speed processors, LPAR environments and networking. A used iSeries can be picked up fairly inexpensively, but then you have licensing issues to contend with for your operating system and any other licensed products that you need to get programming tasks done. If a second machine is not in the cards, it would not be too difficult to take your current system and split it up into two logical partitions, giving one partition to the programmers. That may result in some additional licensing costs, and further investigation would be called for to sort all of that out with your software vendors.

Once you have your programmers isolated that way, they can do whatever they want in their test domain without a chance of affecting production files or processing. Plus, your pro

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT iSeries security tips Checking in on your IBM i authorization lists PCI data security standards and the System i Securing the integrated file system on IBM System i Contextual security on IBM i: Limit user profile access Time for a security checkup for your i Security monitoring on IBM i: Watching your super users Tracking System i program object changes Recovering your AS/400 security configuration System values on i: Setting them up and locking i down A guide to System i security, Part 3: Digging in to the System i security environment iSeries physical security Time for a security checkup for your i Recovering your AS/400 security configuration A guide to System i security, part 2: Landing and establishing access A guide to System i security: Descending into the heart of darkness of IT security Learning guide: Steps to a secure System i Securing printed output 12 security tips in 12 minutes Are all of your System i (iSeries) doors closed? -- part 1 Can you trust all those trigger programs? Learning guide: Simple steps to a secure iSeries

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

grammers will probably love having their own sand box to play in. At one company where we did that, we used that method to train end users on changed applications before they went live and the user's loved it.

With your programmers separated out, you then just need to contend with change control rules. There are some good change control software products on the market, but your company better have deep pockets as many of my readers report that the entry cost is pretty steep.

The things to be concerned about with change control are that you always have a copy of the source code for the applications as they are running in production. When you have a change to a production module, check the source out to the programmer assigned to any changes and then keep track of that until the project is done. When the change is to be implemented, you need to update the various system objects that need to be implemented into production taking care that all ownership and security authorizations are updated to reflect you company's policies. Then, save the current objects in case you need to do a rollback and put the new version in place. When the new versions are implemented, the corresponding source needs to be updated while versioning the prior source code. That's a mouthful, but I think you get the picture. In today's networked world, moving objects from the programmer's system (or partition) over to your production system should be easy and controllable from a security perspective. Consider using a super profile just for that purpose and then track everything done by the profile.

If you have specific questions about this topic, e-mail 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.