If you're reading this, you're probably either a security officer or working in the security group in your iSeries shop. I'll bet, however, that you didn't start your career in the security area but worked your way into your current position, starting as a programmer or a database administrator or some other related field. In your earlier positions, I'm sure you learned a lot of principals about testing. Don't let this fall by the wayside in your current position. Security testing is just as important as application testing.
Today, we'll take a look at testing your user profiles. In future articles, I'll also be taking a look at other testing regimens for your security setup.
The best time to test a user profile is when you initially create it. If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives. (This article will assume that you have your user profiles organized into groups with group profiles active.)
As with all testing, the objective is to check and make sure that the security setup for a user profile (or group) is meeting the objectives you designed. To do this with a new profile, make sure that you set the password to a temporary code and that the PWDEXP parameter is set to *YES. Using this method, the system will allow a single sign-on with the temporary password and then prompt you during sign on to change your password immediately. When you sign on to test the profile, you can then change the password to the user's final password or to another temporary code. If you do this, you'll have to set the PWDEXP back to *YES when you're all done.
The first thing to check on any new profile is to make sure that the sign-on completes successfully. If it fails, look in the special QEZJOBLOG output queue for a joblog for the failed logon session. It is amazing what a joblog can tell you about failures on your system and a close examination of the joblog starting from the top should reveal any problems that have happened to cause the logon process to fail. Typical problems you will encounter include missing or misspelled library names, incorrect initial menu names and incorrect initial program references.
Once you've signed on correctly, then you should exercise the profile to make sure that it meets your objectives. Ask yourself the following questions as you work with the new profile:
- Is the right menu displayed?
- Does the user have access to the command line as designed?
- If an initial program was displayed, did it execute correctly?
- What happens when you press the Attention key function? Is it what you want the user to see?
- Where is printed output going for the session? Is this where you wanted it to go?
- What happens when you attempt to run the application or applications that this user should be using?
- Are there any system tasks that the user should be able to run? Can they?
- Are there specific functions that the user should be barred from? Can you access them?
Make notes for yourself on any issues uncovered, then go back and make any changes that need to be done to bring the profile or group into compliance with your security objectives. If you detect any problems, be sure to repeat the test until everything is OK. At that point, you can turn the profile over to the user.
If you have never tested or audited your current profiles, you can use this same method, but you will have to warn the users that you are doing a review. You can use the PWDEXP parameter on the user profile to help with this testing. Change the user's password to a temporary code for your testing logon. Once you've completed your test, change the PWDEXP parameter to *YES and set a temporary code that you've already told your user about. Then, the next time they log on to your system, OS/400 will ask them for a new password and they're back in business with little interruption to their daily job tasks.
If you have any questions concerning this tip, feel free to contact me directly at rich@kisco.com.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.
==================================
MORE INFORMATION ON THIS TOPIC
==================================
Restricting user's authority
This Search400.com member wanted users to have the capability to
"start" their own writers, but wanted to restrict them from viewing
other people's outqs. What is the best way to go about this? Security
expert Carol Woodbury explains.
Get better control over user profiles
Every iSeries shop has the potential to have active user profiles
on the system for users who have left the company. Unless your
personnel department is extra careful about global notifications
when people leave, you may have a security exposure that you
don't even know about. But you can, if you're careful about
setting up user profiles, take care of this problem when new
profiles are created.
A security no-brainer: analyze default passwords
The checkup that should be performed regularly is Option 1 from the
SECTOOLS Menu (Analyze default passwords). Selecting this option will
print a list of all User Profiles in which the Password exactly
matches the name of the user profile. It's unacceptable for a
password to match a user profile. If they do match, your system is
open to intrusion.
