Q:My question deals with the IBM-supplied library QGPL which ships with public

authority of *CHANGE. Since we put certain production programs in the library,

and it is controlled by our change control software, I would like to change the

public access for library QGPL to *USE. Will I have problems (e.g., system

functions having an authority problem) if I make this change?

A:You can change the authority for the library QGPL from *CHANGE to *USE. IBM

shipped library QGPL with public authority of *CHANGE because it is the default

library for creating objects. If you do change the authority, users who attempt

to insert objects will receive an error message. To prevent objects from being

created into library QGPL, be sure the user's current library (CURLIB) is not

*CRTDFT and does not explicitly name QGPL.

Q: I suspect that one of the programmers in our installation has a program that

adopts access as a security officer. I have changed the QSECOFR password to

prevent the use of the profile.

I used the Display Program Adopt (DSPPGMADP) command to list the programs that

adopt the user profile QSECOFR and the other profiles that have *ALLOBJ and

*SECADM authority. It is difficult, however, to isolate which program the

programmer may be using because the program list is large.

Is there some wayùother than asking the programmerùto determine if the

programmer is calling a program that adopts access as a security officer?

A:An alternative to using the DSPPGMADP command to find programs that adopt

authority is to use the auditing features of OS/400. You can audit events for

individual users or system wide. If you turn on auditing for the individual

programmer, you will be able to see which programs he uses that adopt

authority. Use these steps to record when programs that adopt authority are

used.

1. If you are not already auditing, create the objects needed to start auditing

with these commands.

CRTJRNRCV JRNRCV(jrnlib/AUDJRN0000) +

AUT(*EXCLUDE)

CRTJRN JRN(QSYS/QAUDJRN) +

JRNRCV(jrnlib/AUDJRN0000) +

AUT(*EXCLUDE)

2. Then set the audit control system value to record object and user-level

auditing events, such as authority obtained through authority adoption.

CHGSYSVAL SYSVAL(QAUDCTL) +

VALUE(*AUDLVL)

3. Change the programmer's user profile to record the use of programs that

adopt authority.

CHGUSRAUD USRPRF(programmer) +

AUDLVL(*PGMADP)

I recommend specifying the *PGMADP option only for the individual programmer.

Specifying the *PGMADP option in the Security Auditing Level (QAUDLVL) system

value would record the use of programs that adopt for all users.

When the programmer signs on and uses programs that adopt authority, the system

records the names of these programs. From this list of programs, you should be

able to find the one that is being used to adopt the security officer

authority.

Follow these steps to retrieve the information from the audit journal.

1. Extract the program adopt entries from the audit journal.

DSPJRN JRN(QAUDJRN) +

ENTTYP(AP) OUTPUT(*OUTFILE) +

OUTFILFMT(*TYPE2) +

OUTFILE(yourlib/QASYAPJE)

2. Use Query or another report tool to view the data. In the sample report in

1, the program name is listed twice: once when the program that adopts

Figure 1, the program name is listed twice: once when the program that adopts

authority starts and again when the program ends (as indicated by the S and E

entry types).

Q: I have been reprimanded for accessing a file on the system with *PUBLIC

authority. I work for a company that does not have a security policy. It is my

understanding from the AS/400 Security - Basic manual that IBM strongly

recommends a security policy be communicated verbally, but preferably in

writing.

The system has been installed for several years and has no security. If a

company has public files and has never communicated any policy as to the

responsibility of authorized users of the system, would it be fair to say that

the authorized users of the system have the authority to access any file on the

system?

A: This is not the normal technical issue that I discuss in this column. This

is a business conduct and professional ethics issue. Here are my personal

feelings about the responsibilities of individuals and companies regarding

access to information.

The security policy should be written and communicated to all system users. The

written security policy can clarify the responsibility of users relative to

data access and can strongly deter users from performing questionable

activities.

I agree with you that the security policy should be a written document. I feel

that the individual employee, however, must act responsibly even when there is

no formal security policy. I consider the information stored in a computer to

be like the information stored in the desks of your fellow employees. Even if

they leave their desks unlocked, it is not proper for another person to rummage

through the unlocked desks. The lack of a security policy does not give

individuals the right to access files outside the scope of their job

responsibility.

I have seen many installations that do not have a security policy and do not

use the available security controls. In some systems, the public has the

authority not only to view the files but also to delete the data. I am sure

that you would agree that system users do not have the right to delete the

files. Having the authority to perform an operation does not give an individual

the right to perform the operation.

In the business environment, the employee is expected to protect the

information of the company, including the confidentiality of the information.

The information in the computer files is the property of the company even if it

has been lax in protecting the information.

For those readers who do not have a security policy, this would be an excellent

time to produce one.

Security Patrol: Security Questions & Answers

Figure 1Sample Audit Journal Report

 ENTRY OBJECT LIBRARY OBJECT OBJECT TYPE NAME NAME TYPE OWNER S SECOFR WOE *PGM QSECOFR E SECOFR WOE *PGM QSECOFR