In the first part of this three-part series, Andrew Borts discussed the general overview of everything that needs to be considered for a System i security policy. In part two he delved into setting up the system to allow specific user access and authority and maintain a secure i. Here he directs you through the process of tightening up your system environment.
Now that we've created the concepts for an AS/400 security policy and created a corporate-wide security solution, let's see what we need to do to secure our computers.
Reviewing what we did thus far:
- Took care of physical security (Part 1)
- Created policies and identified what we want to secure (Part 2)
- Communicated the plan to the corporation (Part 1 and Part 2). Please note, that I'm going to nag you until you do this. So, let's just say I mentioned it here in Part 3 and be done with it!
We're now going to investigate how we tighten up our environments for security starting with the system and what needs to be done before we step into the environment.
We authenticated when we got to the office using our PC's -- can we utilize this so we don't need to sign on anymore? In some cases, yes, some no. The area you need to investigate further is a standard server for "directory services" called LDAP. This is a "directory" protocol which has been on the i5 since way back in V4R3 days. LDAP is a fancy data lookup service into a database of centrally stored users and their associated objects. The i5 can see if the user has been authenticated, and in some cases, bypass a sign-on page avoiding one of the MANY prompt for user ID and password. This second sign-on could be an "Achilles heal" for your users, causing them to write down their many User ID's and passwords and open up more holes in your environment.
What about our systems environment?
At last count, there were 36 security system values dealing with restoring objects and their security when restored to the changing and quality of passwords being created. Here is my favorite aspect that needs to be addressed:
- QMAXSGNACN: Action to take for failed signon attempts -- from disabling device you're using to sign on (ineffective if your system creates new devices) disabling the user profile in question, but that requires people being vocal when their profile is disabled, and making note of it and last but not least disabling the device and profile. Now I mention that disabling the devices is ineffective if system value QAUTOVRT – or create virtual devices is set to a level that is too high. If it's set too high, if someone is "hacking" and disabling devices, another one is right there to take it's place when the hacker tries again!
- QMAXSIGN: Maximum sign-on attempts allowed before the system gets mad, and disables the device. Three is a good number – the user must pay attention when they have bad sign on attempts.
- QINACTITV: This setting signs people off the system after the i5/OS detects idle time of more then xx minutes (where you indicate this setting).
- QDSPSGNINF (display sign-on information): I like this setting because you can see if you had attempts on your user ID and report it (e.g., I just had a good sign on, and it said "sign-on attempts not valid").
Click image for larger version
- QPWDEXPITV: Password expiration is an art. Too soon, and your users create a system for their passwords, so if you guess the password, it becomes a number that adds one every month. Not soon enough, and the users become complacent and give out their passwords.
- QPWDLMTAJC: This system value limits adjacent digits in password. This value is either on (1) or off (0).
- QPWDLMTCHR: Limit characters in password. If you want to prevent the passwords from being words then don't allow vowels. Again, it's an art. If you make it too difficult the users write the passwords on the bottom of their keyboards.
- QPWDLMTREP: Will limit repeating characters in a password. One level (1) indicates that letters can't be repeated. The next level up (2) limits consecutive repeats.
- QPWDLVL: This system value sets your password level, which defines length from a maximum of 10 characters, to a maximum of 128 characters. Once you go this route, you may be limiting PC clients using older versions of windows from connecting to your system. This value can be a zero through three. Please make sure that this is what you want, as passwords will also become case sensitive.
- QPWDMAXLEN: Maximum password length – from 1 to 128.
- QPWDMINLEN: Minimum password length – from 1 to 128.
- QPWDPOSDIF: Limit password character positions. This prevents the same password with a new number from being used when it's time to change passwords. Essentially – this forces the characters to change position in a new password.
- QPWDRQDDGT: Requires a digit in password.
- QPWDRQDDIF: Duplicate password control limits the number of times (four to 32) previous passwords can be re-used.
- QPWDVLDPGM: Password validation program. For use if you have more stringent password intervals.
- QSECURITY: System security level. The minimum security should be 30. The operating system ships at 40 or OS level security, so you have a fighting chance at minimum security.
There is also a seldom-used tool built into the operating system that you can access by typing "go security" and hitting enter. Here you can find many security tools and wizards to help you change your environment to your liking. Warning: you can potentially lock yourself out of your own system! So please read up on these tools. Read the CFGSYSSEC (configure system security) command documentation for more information.
Object level security is a necessity on the AS/400. The idea is that if someone were to "hack" into your system, what would they have access to? Hopefully, not much. So keep your objects secured to a group profile, or to an authorization list.
Also, turn on security auditing so you can review journal entries of changed security items. You can choose events and place them into the QAUTLVL system value and indicate which security events you want audited.
The system ships with minimum security level 40 that "hardens" the operating system against any hands that shouldn't be touching the system objects. The OS also locks out API's that may be harmful.
There you have it, my three part security overview is completed. This is an enormous topic, and can become a full-time job for someone at a larger company. Remember, salt to taste, and take this project one bite at a time. And try not to chew off too much at once!
ABOUT THE AUTHOR: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.
