Plan resource security

This topic describes each of the components of resource security and how they all work together to protect information on your system. It also explains how to use CL commands and displays to set up resource security on your system.

Resource security defines which users are allowed to use objects on the system and what operations they are allowed to perform on those objects.

Defining Who Can Access Information

You can give authority to individual users, groups of users, and the public.

Note: In some environments, a user’s authority is referred to as a privilege.

You define who can use an object in several ways:

Public Authority: The public consists of anyone who is authorized to sign on to your system. Public authority is defined for every object on the system, although the public authority for an object may be *EXCLUDE. Public authority to an object is used if no other specific authority is found for the object.
Private Authority: You can define specific authority to use, or not use, an object. You can grant authority to an individual user profile or to a group profile. An object has private authority if any authority other than public authority, object ownership, or primary group authority is defined for the object.
User Authority: Individual user profiles may be given authority to use objects on the system. This is one type of private authority.
Group Authority: Group profiles may be given authority to use objects on the system. A member of the group gets the group’s authority unless an authority is specifically defined for that user. Group authority is also considered private authority.
Object Ownership: Every object on the system has an owner. The owner has *ALL authority to the object by default. However, the owner’s authority to the object can be changed or removed. The owner’s authority to the object is not considered private authority.
Primary Group Authority: You can specify a primary group for an object and the authority the primary group has to the object. Primary group authority is stored with the object and may provide better performance than private authority granted to a group profile. Only a user profile with a group identification number (gid) may be the primary group for an object. Primary group authority is not considered private authority.

See Plan object authority for more object authority information.

Planning resource security

Now that you have completed the process for planning users on your system, you can plan the resource security which protects objects on the system. In Resource security you learn how to set up resource security on your system.

System values and user profiles control who has access to your system and prevent unauthorized users from signing on. Resource security controls the actions that authorized system users can perform after they have signed on successfully. Resource security supports the main goals of security on your system to protect:

Confidentiality of information
Accuracy of information to prevent unauthorized changes
Availability of information to prevent accidental or deliberate damage

You may plan resource security differently, depending on whether your company develops applications or purchases them. For applications you develop, you should communicate the requirements for security of the information to the programmer during the application design process. When you purchase applications, you need to determine your security needs and match those needs with the way your provider has designed your applications. The techniques described here should help you in both cases.

This information provides a basic approach to planning resource security. It introduces the main techniques and shows how you can use them. The methods described here will not necessarily work for every company and every application. Consult your programmer or application provider as you plan resource security.

The following sections are provided to help you plan resource security: [list of active links to children]

Resource security
Understanding types of authority
Planning security for application libraries
Determining ownership of libraries and objects
Grouping objects
Protecting printer output
Protecting workstations
Implementing resource security
Planning your application installation

The following planning forms are helpful when planning system level security:

Complete an Application description worksheet for each application on your system.
Reference Plan object authority to plan how you will establish ownership and public authority to your applications after you load them.
Use the Authorization list worksheet to list the objects that the list and the groups and individuals who have access to the list secure.
Use the Printer Output Queue and Workstation Security worksheet to list any workstation or output queue that requires special protection.

Determining your objectives for your resource security: To begin to plan resource security, you must first understand your objectives. The system provides flexible implementation of resource security. It gives you the power to protect critical resources exactly the way you want. But resource security also introduces additional overhead to your applications. For example, whenever an application needs an object, the system must check the user’s authority to that object. You must balance your need for confidentiality against the cost of performance. As you make resource security decisions, weigh the value of security against its cost. To prevent resource security from degrading the performance of your applications, follow these guidelines:

Keep your resource security scheme simple.
Secure only those objects that you need to secure.
Use resource security to supplement, not replace, the other tools for protecting information, such as:
- Limiting users to specific menus and applications.
- Preventing users from entering commands by limiting capabilities in user profiles.

Begin your resource security planning by defining your objectives. You can define your security objectives on either the Application Description form or the Library Description form. The form that you use depends on how your information is organized in libraries.

Planning security for workstations: After planning resource security for printers and printer output, you can begin planning workstation security. On your Physical Security Plan, you listed workstations that represent a security risk because of their location. Use this information to determine which workstations you need to restrict.

You can encourage the people who use these workstations to be particularly aware of security. They should sign off whenever they leave their workstations. You may want to record your decision about sign off procedures for vulnerable workstations in your security policy. You can also limit which functions can be performed at those workstations to minimize the risks.

The easiest method for limiting function at a workstation is to restrict it to user profiles with limited function. You may choose to prevent people with security officer or service authority from signing on at every workstation. If you use the QLMTSECOFR system value to do this, people with security officer authority can sign on only at specifically authorized workstations. Prepare the workstation portion of the Output Queue and Workstation Security form.

Summary of resource security recommendations: After you finish planning workstation security, you can review the following resource security recommendations. The system offers many options for protecting the information on your system. This gives you the flexibility to design the resource security plan that is best for your company. But this wealth of options can also be confusing. This information demonstrated a basic approach to planning resource security that uses these guidelines:

Move from the general to the specific:
- Plan security for libraries. Deal with individual objects only when necessary.
- Plan public authority first, followed by group authority, and individual authority.
Make the public authority for new objects in a library (CRTAUT) the same as the public authority you defined for the majority of existing objects in the library.
Try not to give groups or individuals less authority than the public has. This diminishes performance, may lead to mistakes later, and makes auditing difficult. If you know that everyone has at least the same authority to an object that the public has, it makes planning and auditing security easier.
Use authorization lists to group objects with the same security requirements. Authorization lists are simpler to manage than individual authorities and aid in recovery of security information.
Create special user profiles as application owners. Set the owner password to *NONE.
Avoid having applications owned by IBM-supplied profiles, such as QSECOFR or QPGMR.
Use special output queues for confidential reports. Put the output queue in the same library as the confidential information.
Limit the number of people who have security officer authority.
Be careful when granting *ALL authority to objects or libraries. People with *ALL authority can accidentally delete things.

To ensure that you have planned successfully for setting up resource security, you should have gathered the following information:

Fill in Part 1 and Part 2 of the Library description forms for all your application libraries.
On your Individual user profile forms fill in the Owner of objects created and Group authority over objects created fields.
On your Naming conventions form describe how you plan to name authorization lists.
Prepare Authorization List forms.
Add authorization list information to your Library description forms.
Prepare an Output queue and workstation security form.

Now you are ready to plan your application installation.

End of Step 3 for planning a security strategy; provide link to next step: Plan network security