Plan security for programmers

Programmers pose a problem for the security officer. Their knowledge makes it possible for them to bypass security procedures that are not carefully designed.

Programmers can bypass security to access data they need for testing. They can also circumvent the normal procedures that allocate system resources in order to achieve better performance for their own jobs. Security is often seen by them as a hindrance to doing the tasks required by their job, such as testing applications. However, giving programmers too much authority on the system breaks the security principle of separating duties. It also allows a programmer to install unauthorized programs.

Guidelines for setting up an environment for application programmers:

Do not grant all special authorities to programmers. If you must give programmers special authorities, give them only the special authority required to perform the jobs or tasks assigned to the programmer.
Do not use the QPGMR user profile as a group profile for programmers. Use test libraries and prevent access to production libraries.
Create programmer libraries and use a program that adopts authority to copy selected production data to programmer libraries for testing.
If interactive performance is an issue, consider changing the commands for creating programs to run only in batch: CHGCMD CMD(CRTxxxPGM) ALLOW(*BATCH *BPGM)
Perform security auditing of application function before moving applications or program changes from test to production libraries.
Use the group profile technique when an application is being developed. Have all application programs owned by a group profile. Make programmers who work on the application members of the group and define the programmer user profiles to have the group own any new objects created (OWNER(*GRPPRF)). When a programmer moves from one project to another, you can change the group information in the programmer’s profile. See Group Ownership of Objects for more information.
Develop a plan for assigning ownership of applications when they are moved into production. To control changes to a production application, all application objects, including programs, should be owned by the user profile designated for the application.
Application objects should not be owned by a programmer because the programmer will have uncontrolled access to them in a production environment. The profile that owns the application may be the profile of the individual responsible for the application, or it may be a profile specifically created as the application owner.

Managing Source Files

Source files are important to the integrity of your system. They may also be a valuable company asset if you have developed or acquired custom applications. Source files should be protected like any other important file on the system. Place source files in separate libraries and controlling who can update them and move them to production.

When a source file is created on the system, the default public authority is *CHANGE, which allows any user to update any source member. By default, only the owner of the source file or a user with *ALLOBJ special authority can add or remove members. In most cases, this default authority for source physical files should be changed. Programmers working on an application need *OBJMGT authority to the source files to add new members. The public authority should probably be reduced to *USE or *EXCLUDE, unless the source files are in a controlled library.

Planning Security for System Programmers or Managers

Most systems have someone responsible for housekeeping functions. This person monitors the use of system resources, particularly disk storage, to make sure that users regularly remove unused objects to free space. System programmers need broad authority to observe all the objects on the system. However, they do not need to view the contents of those objects.

You can use adopted authority to provide a set of display commands for system programmers, rather than giving special authorities in their user profiles.