Work Management Standards › Implementation of Security › Generic Implementation of Security › Security Exposure

Security Exposure

Most of the likely points of security exposure are covered in the chapter on security in the IBM i (AS/400) CL Programmer’s Guide.

Standards can be adopted to protect from potential exposure on the following points:

• Old passwords. Passwords should be changed regularly. The password change date can be used to monitor this. Use the OS/400 QPWDEXPITV command to enforce regular changing of passwords.
• Password validation. Validate new passwords:
  • to be long enough to prevent systematic code breaking, that is, at least eight characters
  • to have non-obvious values, that is, neither user profile names or other common values; for example FRED, IBM, ME are all obvious values
• Allowed Signons. Set the OS/400 system value that controls the number of allowed signon attempts, QMAXSIGN to a low value, for example, three.
• Sign on levels. You should use two-level password security. On IBM i, QSECURITY should be set to 30 or 40 rather than single-level password security. This makes it impossible for users to inadvertently discover each other's passwords.
• Workstations left signed on. Use the OS/400 QINACTITV system value to force a time out after a specified number of seconds.
• Programs that adopt rights. A particular potential exposure is presented by programs which, although they themselves are secure, adopt owner rights created with USRPRF(*OWNER)) and call other programs. Infiltrators may attempt to replace the called objects with their own "Trojan horses" that will have the adopted rights of the calling program. Programming knowledge is needed to do this. If security is a paramount consideration, you should do the following:
  • Make sure that debug capability is removed from programs that call the OS/400 QCMDEXC program.
  • Create adopting programs with LOG(*NO) and ALWRTVSRC(*NO). This makes it harder to determine the exit points for inserting "Trojan horses". On IBM i, you can delete the observability of such programs using the OS/400 Change Program (CHGPGM) command. This makes dump analysis impossible.
  • Secure the library containing the called program by revoking object management rights to it. Also, either qualify the program call statements by including a library name for the called program, or place programs called by the adopted program in the system part of the library list and revoke object rights to the OS/400 Change System Library List (CHGSYSLIBL) command. You should probably do this in any case.
  • Restrict the adoption of rights to the minimum duration. That is, place the statements for which rights must be adopted in a small, separate subprogram.
  • Override any files that are used with SECURE(*YES).

Note: Avoid creating programs that adopt the rights of profiles with QSECOFR rights.

• Input and media. Make sure that you apply adequate security measures to your offline backup media (tapes and diskettes) and to printout.
• Use of PRTTXT. Use the PRTTXT keyword to ensure that all printouts have originating text on it, for example ‘IBM RESTRICTED’.